The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
I use tape all the time. As a verb. Why just yesterday I taped a message. On the side of my computer, so I would be reminded to do something.
Floppy disks were indeed floppy. That was before they made them hard. Especially if you took them out of the wrapper they were in. Yes, after spilling a soft drink on a floppy, I did take one out, wash it off and put it in another so I could still use it. I figure the next best thing will be flexible electronics, so everything will be floppy again.
So, if we shouldn't use "search engine", is it OK to use "search engines" to refer to the whole group of Bings and Googles and ... ?
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
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!
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.
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.
But stage is already taken by the ... well, stage (the thing you add to before you commit it)
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.
My 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.
I 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.
I 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.
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.