Back in a prior post, I wrote an introduction to git, a new open source version control package. I’ve since been learning more about it, especially reading much of the O’Reilly book “Version Control with Git” by Jon Loeliger over the holiday break. There are a few things which I’ve found just a little confusing or surprising coming from a cvs/svn background, in addition to the concept of a distributed repository system. I’d like to talk about one just a little, but first, I’d like to apologize for this incorrect statement from last time:
It can then be pointed to a different SVN server – from the same sandbox! Magic!
It turns out that’s not true – a git sandbox can point to any number of remote git repositories, but only to at most one remote svn server. All is not lost, however, since you can have two git sandboxes, each pointing to one svn server, but as git remotes of each other. Thanks to Brian Powell for sending me
this link.
I actually think you can point to two branches in the same svn site from one git directory, but you have to tell it how the branches are layed out in the “git svn clone” operation. I haven’t tried it yet, though.
The Index
The concept of the index is new to me, and something I didn’t come to appreciate until working with git for a bit. It is a staging area for building up your next commit, between the working directory and the repository. You can have changes going on which should logically be checked in separately – you add the first set to the index with “git add file1”, then commit with “git commit”, leaving changes to file2 to be checked in later, assuming the changes aren’t all in the same file.
Also, “git diff” is a diff between the working directory and the index, not a diff between the working directory and the latest commit (HEAD), as is the case with cvs and svn. To get the diff from the last commit, use instead “git diff HEAD”. Likewise, “git diff –cached” is the diff between the HEAD and the index, showing what would be checked in with a “git commit”.
Also, when doing a “git pull” or a “git merge”, only the conflicts show up with “git diff”. I’ve been caught by this one, thinking I knew what all had arrived in a “git pull” from a colleague! I think the advice of sticking to “git fetch” rather than “git pull” is one I’ll try. By the way, “git pull” is a “git fetch” followed by a “git merge”.
I’m still committed to getting more comfortable with git and using it more intelligently. We got a proposal funded which will involve me having to work with svn at two remote sites in two different states, one of which is now woefully out of date. Call it a New Year’s resolution to get that fixed with git!