Get Git?

Note: William recently evalutated git for a project he’s been working on. This article is based on his email summary.

I’ve been meaning to look into “git” for a long time. Been collecting info for weeks. So today I decided to put that research to work, to try Git out, and to write a review. In a sentence:

I would not recomend Git at this time.

Though nice for some uses (distribution, branching, and merging), Git isn’t remarkable in any other way.

Summary

I’m an egotistical bastard, and I name all my projects after myself. First “Linux”, now “git”. (Linus Torvalds)

Linus made Git because Linux needed version control after the keepers of BitKeeper decided that they didn’t like kernel developers. Git is distributed. This means that each developer has in own repository to which he commits. Changes are shared by pulling from or pushing to a repository. We can talk a lot about distributed version control, but we really want to know about Git.

Is Git good? Should we get Git? Can we use Git as a CVS or SVN replacement? I can’t say what we should do, but I can give my perspective.

Git is good if you want to be able to merge branches and if you want the benefits of distributed version control: local commits, fast history, offline access. Besides those perks Git seems nicer but not remarkably nicer than SVN.

What about modules? It’s a work in progress, but they have a good feel for problem space including how I understand modules in our project. I’m not even sure if our use of modules would matter with Git. I’ve heard it said that we use CVS modules to limit how much you need to check out. However, with distributed version control you’re going to check out he whole repository anyway which is much, much more than a normal working copy. Git is designed to make this tolerable for the Linux Kernel, so if checkout/update savings is the primary goal of modularity in our current system, perhaps it’s not necessary. But that’s just my perspective.

What is my perspective? I don’t like command-line tools. I loath their obscurity and unnecessarily complex. I do like them when invocation short, sweet, and just does the right thing. As a rule, UNIX tools seem bent on doing the wrong thing unless you know the poorly documented flags that everyone always uses, but aren’t the defaults.

With version control, I like the idea of distribution. But Darcs and Mercurial haven’t impressed. I could hardly try them out. They both were intolerable. (This may be change, or they may have already changed.) Despite several frustrations, Subversion, I can stand so long as we don’t include merging among Subversion’s feature set. Of CVS, I agree that it’s not the answer:

CVS is not the answer, CVS is the question. No is the answer. — Theodore Ts’o

That’s my perspective. What follows is how I reached my conclusion about Git.

Installation

If installation isn’t easy, then I’ll stop right here. Perfect ten requires a single click download and a single click install. The download is one click from the Git Home Page.

As a UNIXy tool, we’re looking at a make; make install. make fails. Google . Dependency:

 wget http://surfnet.dl.sourceforge.net/sourceforge/expat/expat-2.0.1.tar.gz
 tar xzvf expat-2.0.1.tar.gz
 cd expat-2.0.1
 ./configure
 make
 make check # 100%: Checks: 50, Failed: 0
 sudo make install

Retry. Success. Score: 5/10. Worked but required make and an unmentioned dependency.

Tutorial

The primary user interface to a command line tool is its documentation. Let’s see how Git goes. The Subversion Book was okay. Good enough to make Subversions limitations (merging) glaring: good documentation reveals a tool’s flaws.

First we start with the Git Tutorial . Perfect ten requires that the writing be clear, that every instruction is easy to follow and works as expected, and that by the end I have a feel for Git’s capabilities, limitations, how to use it, what to use it for, and whether it’s worth using.

The tutorial wasn’t very clear. Linus differentiates between “plumbing” and “porcelain”. Porcelain refers to the nice commands accessed primarily by calling plain `git`. `plumbing` refers to the more low level commands that have the `git-` prefix. There are 142 such commands. When explaining a concept, Linus starts with the plumbing and then, usually at the end, says, “Again, normally you’d never actually do this by hand. There is a helpful script … that will do all of this for you. So you could have just written … instead, and it would have done the above magic scripting for you.” For a tutorial, you’re should just say what to do to get a desired effect. Later, you can explain how the effect is achieved as a sequence of more primitive actions.

The tutorial is 90% correct. All of the commands work as advertised. Some of the output differs.

The biggest problem with coverage is that you don’t get a good sense for the edges of Git. What doesn’t Git do? What basic things must I know to get by? The quick reference is better at answering this question. Though I count it under clarity, the biggest coverage problem is that there are too many details in the tutorial. Don’t give options, just say, “Here’s the way to do it. If you need something different, there are ways and means to do it.”

• Clarity: 3/10. Too many irrelevant details.
• Correctness: 9/10. Minor output mismatches.
• Coverage: 5/10. Basic tasks covered, but no sense for the edges. What do I need to understand to use Git at the basic level? What should I study to become a master git?

More Documentation

So the main tutorial wasn’t too hot. These are better:

• Simpler Tutorial
• For SVN people
• Modular Subproject Support

I wanted to try Git out more, but I really should be getting back to work.

Further Reading

• Wikipedia entry
• Git entities
• Review about Darcs and git-citool
• Review from SVN perspective
• Review about fear of trying something new
• Tutorial