Git rant, Part II - the word is the thing
-
H.Brydon wrote:
When you checkout a book from a library
no one else can read it. That's not how version control works. In CMS it's RESERVE, like reserving a table in a restaurant -- others can see it but only you can use it. And if you reserve it but don't use it people start complaining and telling you to UNRESRERVE it if you're not actually going use it.
Okay I'll agree with that... but in a library with conventional books (ie. the paper kind) you don't have to checkout a book to read it or photocopy something in it. If you checkout something, it is in 'checked out' status until it is returned to the library and goes through the checkin process. Conventional SCMs treat a checkout as "gimme a copy" without any gateway mechanism or record of who has it checked out. That's not really a checkout in the conventional sense. My point is that an SCM checkout doesn't really check anything out.
-- Harvey
-
So I'm realizing that part of my problem is with the terminology. I expect "commit" to mean "save changes to the remote repository." I expect "checkout" to mean "get the changes from the remote repository." The fact that all the documentation I read about Git uses those same words, but with completely different meaning, leads to a huge amount of confusion and conflict with my mental picture of a VCS. To all the potential git authors / bloggers / developers out there: I have no problem with local repositories, staging areas, stashes, whatever, but PLEASE, use different words because they have different meanings. For example, "commit" in Git could be better described using the word "stage". Committing, the way non-git'ers think about it, could be better described using the phrase "push stage" or something similar. In fact, I don't think the word "commit" should be used at all with Git! Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My BlogMy feeling is that there is a lack of understanding of the concept of a hierachy of repositories. When the file is added to your local repo it is being committed in the classic VCS sense, as it is being added/updated in a versioned controlled repository. The difference is that the respository is (typically) personal rather than (unusually) shared. When you copy your versions to the remote location you are combining together repositories, which is quite a different act to the commit of a number of files.
-
So I'm realizing that part of my problem is with the terminology. I expect "commit" to mean "save changes to the remote repository." I expect "checkout" to mean "get the changes from the remote repository." The fact that all the documentation I read about Git uses those same words, but with completely different meaning, leads to a huge amount of confusion and conflict with my mental picture of a VCS. To all the potential git authors / bloggers / developers out there: I have no problem with local repositories, staging areas, stashes, whatever, but PLEASE, use different words because they have different meanings. For example, "commit" in Git could be better described using the word "stage". Committing, the way non-git'ers think about it, could be better described using the phrase "push stage" or something similar. In fact, I don't think the word "commit" should be used at all with Git! Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My BlogI think the word to meaning changes have much to do with the Linus Torvalds[^] absolutely hating the way svn, tfs and others did things and deciding to develop git in a vacuum (sort of speak) as in completely throwing the baby out with the bath water in terms of the conventions that developers were familiar with and starting over from scratch. Like learning Chinese and then learning Spanish. They both have ways of saying I am hungry but that is where the similarities end. Note: I know nothing of either languages but, it was a wild guess that they have no influence on each other.
-
So I'm realizing that part of my problem is with the terminology. I expect "commit" to mean "save changes to the remote repository." I expect "checkout" to mean "get the changes from the remote repository." The fact that all the documentation I read about Git uses those same words, but with completely different meaning, leads to a huge amount of confusion and conflict with my mental picture of a VCS. To all the potential git authors / bloggers / developers out there: I have no problem with local repositories, staging areas, stashes, whatever, but PLEASE, use different words because they have different meanings. For example, "commit" in Git could be better described using the word "stage". Committing, the way non-git'ers think about it, could be better described using the phrase "push stage" or something similar. In fact, I don't think the word "commit" should be used at all with Git! Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My BlogI don't think in this particular case it's the wording. Git uses a significantly different model than most centralized VCSs. Essentially, git doesn't manage versions, it manages patches, and lets you mix and match these at will. While at it, it takes great care to keep a history of all the mixing and matching you did. Now, this pretty much make the notion of a version in the way other VCSs define and use it vanish. And that's where the big problem lies. Head is just a convention, there's nothing that makes head essentially different from any other branch, other than people connecting to a repo designating it as head and the repo forcing you to merge in patches previously merged on head if you want to add another patch. But in the end it's still just a collection of patches. [Off topic from here onwards] The model is quite flexible and powerful, but I don't think there are many dev shops actually needing this power. Your customer doesn't want several branches, he just wants head, so eventually you need to merge every patch into head. Why bother with patch management at its best, then? This whole patch management headache makes sense when you maintain the Linux kernel (quite a few million), receive lots of patches from thousands of developers (about a million lines were deleted/removed or changed from the 3.3 to 3.5 dev version evolution) and have different distros merge and match distinct sets of patches from one version to the next, a traditional VCS won't cut it. IMO, it makes sense to see where you stand between two extremes: the single developer which just wants to track his sources, and doesn't maintain distinct branches, and the Linux kernel. Depending on where you stand, git might absolutely not make sense. Or svn. What I've seen people do is use git for configuration management. This is IMO brain-damaged. Git is a VCS, not a tool for managing binary variants of distinct libs, apps and the like.
-
So I'm realizing that part of my problem is with the terminology. I expect "commit" to mean "save changes to the remote repository." I expect "checkout" to mean "get the changes from the remote repository." The fact that all the documentation I read about Git uses those same words, but with completely different meaning, leads to a huge amount of confusion and conflict with my mental picture of a VCS. To all the potential git authors / bloggers / developers out there: I have no problem with local repositories, staging areas, stashes, whatever, but PLEASE, use different words because they have different meanings. For example, "commit" in Git could be better described using the word "stage". Committing, the way non-git'ers think about it, could be better described using the phrase "push stage" or something similar. In fact, I don't think the word "commit" should be used at all with Git! Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My BlogYeah. It is the result of a geek (he who must not be named) working over a weekend and no one reviewing the work. If the lord himself wrote it, it must be you who is stupid enough not to understand it, right?
-
So I'm realizing that part of my problem is with the terminology. I expect "commit" to mean "save changes to the remote repository." I expect "checkout" to mean "get the changes from the remote repository." The fact that all the documentation I read about Git uses those same words, but with completely different meaning, leads to a huge amount of confusion and conflict with my mental picture of a VCS. To all the potential git authors / bloggers / developers out there: I have no problem with local repositories, staging areas, stashes, whatever, but PLEASE, use different words because they have different meanings. For example, "commit" in Git could be better described using the word "stage". Committing, the way non-git'ers think about it, could be better described using the phrase "push stage" or something similar. In fact, I don't think the word "commit" should be used at all with Git! Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My BlogAnother major issue is that sites like github do such a good thing in masking (via their excellent UI) all these shortcomings of a bad CLI so that these issues are even less of issues to most.
-
So I'm realizing that part of my problem is with the terminology. I expect "commit" to mean "save changes to the remote repository." I expect "checkout" to mean "get the changes from the remote repository." The fact that all the documentation I read about Git uses those same words, but with completely different meaning, leads to a huge amount of confusion and conflict with my mental picture of a VCS. To all the potential git authors / bloggers / developers out there: I have no problem with local repositories, staging areas, stashes, whatever, but PLEASE, use different words because they have different meanings. For example, "commit" in Git could be better described using the word "stage". Committing, the way non-git'ers think about it, could be better described using the phrase "push stage" or something similar. In fact, I don't think the word "commit" should be used at all with Git! Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My BlogWell, let's compare SVN's commit command to git. In SVN a commit saves a set of changes to the repository. This is what you do in Git as well. The main difference is that in git your repository is located in your .git folder. Fetch and push in git is simply commands that you use to synch repositories. Git uses the correct terminology, keep in mind that there is no technical difference between a git repository on your development server and on your machine. You simply use them differently.
-
So I'm realizing that part of my problem is with the terminology. I expect "commit" to mean "save changes to the remote repository." I expect "checkout" to mean "get the changes from the remote repository." The fact that all the documentation I read about Git uses those same words, but with completely different meaning, leads to a huge amount of confusion and conflict with my mental picture of a VCS. To all the potential git authors / bloggers / developers out there: I have no problem with local repositories, staging areas, stashes, whatever, but PLEASE, use different words because they have different meanings. For example, "commit" in Git could be better described using the word "stage". Committing, the way non-git'ers think about it, could be better described using the phrase "push stage" or something similar. In fact, I don't think the word "commit" should be used at all with Git! Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My Blog -
So I'm realizing that part of my problem is with the terminology. I expect "commit" to mean "save changes to the remote repository." I expect "checkout" to mean "get the changes from the remote repository." The fact that all the documentation I read about Git uses those same words, but with completely different meaning, leads to a huge amount of confusion and conflict with my mental picture of a VCS. To all the potential git authors / bloggers / developers out there: I have no problem with local repositories, staging areas, stashes, whatever, but PLEASE, use different words because they have different meanings. For example, "commit" in Git could be better described using the word "stage". Committing, the way non-git'ers think about it, could be better described using the phrase "push stage" or something similar. In fact, I don't think the word "commit" should be used at all with Git! Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My BlogQuote:
I expect "commit" to mean "save changes to the remote repository." I expect "checkout" to mean "get the changes from the remote repository."
Hmmm, I think you nailed the problem right here in your statement. You use the word "remote" twice. The premise is in git is that you are the repository.
-
So I'm realizing that part of my problem is with the terminology. I expect "commit" to mean "save changes to the remote repository." I expect "checkout" to mean "get the changes from the remote repository." The fact that all the documentation I read about Git uses those same words, but with completely different meaning, leads to a huge amount of confusion and conflict with my mental picture of a VCS. To all the potential git authors / bloggers / developers out there: I have no problem with local repositories, staging areas, stashes, whatever, but PLEASE, use different words because they have different meanings. For example, "commit" in Git could be better described using the word "stage". Committing, the way non-git'ers think about it, could be better described using the phrase "push stage" or something similar. In fact, I don't think the word "commit" should be used at all with Git! Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My BlogMarc Clifton wrote:
I expect "commit" to mean "save changes to the remote repository." I expect "checkout" to mean "get the changes from the remote repository."
I think, as other have mentioned, this is where the problem lies. 'commit' and 'checkout' still mean the same thing as in SVN, it's just that you are working with a local repository, instead of the remote one. I have been using SubVersion for years, both at work and for my personal projects. I signed up for a GitHub account a while ago to check what all the fuss was about, and never really started using it. It was too complex and confusing. I felt just like you do ;) Recently, I started collaborating on another project which was hosted on GitHub. This forced me to learn the mechanics of Git. Took me quite a while, and I still have the Git Book[^] open in a browser window whenever I need to do anything more than a local commit, but I am starting to see the advantages... especially for multi-developer projects. Not sure if I would use it for solo projects, but then again unless I know I am never going to make this code available to anyone else, I might as well use something where I can easily manage outside contributions.