On Switching to Git

Yes, I switched all my source control to git. I don't have a lot of insight to share so far, but I doubt I'm going to change back.

I work solo, only moving between a desktop and a laptop, so I'm not making huge use of the distributed capability. My previous writing on Git was occasionally mildly criticised for "ignoring" that aspect of Git. I'm not ignoring it, but I lack an understanding of how it really helps me. No, what's great about Git so far is the power of the tools for everyday operations. I'll mention the three that come to mind immediately:

git add -i

Interactive adding is a feature that, once tasted, I could never again live without. Clean-as-you-go is an important part of programming any large system which will inevitably have some crusty corners or old code that needs updated. Without the ability to selectively commit diff hunks, cleaning code as you go leaves you with the Tangled Working Copy Problem when you want to commit.

With Git, I work on a feature and feel free to tidy comments, whitespace and adopt the dot accessor as I go. Later, I can go through the file and pick out the feature hunks, commit those, then commit the rest of the tidying-up work.

git bisect

Bisect is an unbelievably useful tool. It helps you to isolate the commit that introduced a bug. You give it a known-good commit, a known-bad commit and it searches through the commits in between, repeatedly checking out versions for you which you then test and tell Git whether that commit was good or bad. I've isolated several bugs with this already. It's fantastic.

git log

The tools that Git gives you to manipulate, search and output the commit logs are very powerful. There are too many options to discuss each here, but I find the ability to format the output with very fine control is particularly useful. With a little care in writing the first line of commit messages, I can use git log to produce a rough set of release notes (I don't have the exact command line on this machine to copy and paste right now).

speed, etc.

Performance is a feature, and Git is blazingly fast (unless you want to check in very large files). I don't know if it's the new-toy effect, or that I've been working like crazy, or that interactive commit makes it easier, but I find that I've made many more commits than I usually do. This really helps for the odd time that one might, er, accidentally introduce a bug.

What's Been Hard?

The first thing that was hard was pushing my converted SVN repositories to Github. Not that there was anything wrong with Github, but Git just wanted to eat all my RAM and then some more. This was with the FlickrExport repository of ~1000 commits. It turned out that Git was attempting to repack the repository before transmitting it. It appears that Git does this with no concern for the RAM requirements of doing so (sorry, Git fans, I don't have a better explanation right now). In the end, I had to run git gc --window-memory=200m by hand to limit RAM usage, and then push it to Github.

With any change comes some unlearning. One of the biggest things is that you do everything in Git in one directory. If I had branches in Subversion, I was used to having them in different paths. In Git, you're always in the same place. Sometimes, I forgot which branch I was working on. Fortunately, Jon Maddox posted some really useful bash-fu to put the current Git branch in the shell prompt. Problem solved.

I'm slowly getting used to git stash but, this morning, I sat down to my machine and, well, where was all the code I wrote last night? It seemed to be gone! Twenty minutes of poking around later, I remembered that I had done git stash the previous night in order to build a specific tag and had not un-stashed it. Again, problem solved but not without a little panic.

So, in summary, Git's a great tool. It's about way more than just being distributed, though. There's a quieter evolution going on in the more mundane parts of SCM too.