Git rant, Part II - the word is the thing
-
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 BlogMarc Clifton wrote:
I don't think the word "commit" should be used at all with Git!
You don't the developers should all be committed? :confused:
-
Marc Clifton wrote:
I don't think the word "commit" should be used at all with Git!
You don't the developers should all be committed? :confused:
Well, generally we are afraid of commitment...
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
-
Well, generally we are afraid of commitment...
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
That's what makes version control so desirable.
-
Marc Clifton wrote:
I don't think the word "commit" should be used at all with Git!
You don't the developers should all be committed? :confused:
Good point! Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My Blog -
That's what makes version control so desirable.
Indeed. Making a branch...
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 BlogYeah, in fact while we are at it, I disagree with the term "checkout" because you are just retrieving a local copy of the file in question. When you checkout a book from a library, you have total control of it until you return it ("checkin"). I worked with another (corporation private) source code system where you really did checkout the file. If you did so, you 'owned' it until you checked it back in and nobody else could touch it. A concurrent checkout feature later appeared, which is similar to what all of the other SCMs do, but it had a different verb.
-- Harvey
-
Yeah, in fact while we are at it, I disagree with the term "checkout" because you are just retrieving a local copy of the file in question. When you checkout a book from a library, you have total control of it until you return it ("checkin"). I worked with another (corporation private) source code system where you really did checkout the file. If you did so, you 'owned' it until you checked it back in and nobody else could touch it. A concurrent checkout feature later appeared, which is similar to what all of the other SCMs do, but it had a different verb.
-- Harvey
Exactly. Great point. Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My Blog -
Yeah, in fact while we are at it, I disagree with the term "checkout" because you are just retrieving a local copy of the file in question. When you checkout a book from a library, you have total control of it until you return it ("checkin"). I worked with another (corporation private) source code system where you really did checkout the file. If you did so, you 'owned' it until you checked it back in and nobody else could touch it. A concurrent checkout feature later appeared, which is similar to what all of the other SCMs do, but it had a different verb.
-- Harvey
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.
-
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 BlogBut stage is already taken by the ... well, stage (the thing you add to before you commit it) :cool: But you are right, understanding that everything except push and fetch happen on the local repository took a while to get used to. And git terminology is so overwhelming it sucks. It'll bombard you with mystic messages on every step.
-
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 BlogLooks like you just don't 'Git' it, eh? ;P ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... Sorry. ... ... ... ... (Neither do I!)
Bob Dole
The internet is a great way to get on the net.
:doh: 2.0.82.7292 SP6a
-
Looks like you just don't 'Git' it, eh? ;P ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... Sorry. ... ... ... ... (Neither do I!)
Bob Dole
The internet is a great way to get on the net.
:doh: 2.0.82.7292 SP6a
Oh, go on, git out of town! :) Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My Blog -
Oh, go on, git out of town! :) Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My Blogbrisingr@gryphon-pc ± git quit "I HATE GIT!" Git has quit. brisingr@gryphon-pc $
Bob Dole
The internet is a great way to get on the net.
:doh: 2.0.82.7292 SP6a
-
Oh, go on, git out of town! :) Marc
Latest Article: Intertexti - Resurrecting Apple's HyperCard
My BlogHey Marc, I'll hold him/her/it down while you do the kicking.
Software Zen:
delete this; -
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.
