Lu cat !

Scott (no, Clint, I don’t know why he’s still on Planet Debian…), I would have expected a little more from you than your previous post on why you chose bazaar!

I can tell you why you chose bazaar: because you had to, because you are being paid to use it. But what do I care? I found bazaar to be so amazingly slow on any reasonably-sized repository, that I quickly moved on after trying it for a couple of weeks. But that doesn’t say anything about you. So by all means, enjoy bazaar…

… but stop spreading fud about git, which you apparently don’t understand. Git is less of a version control system than it is a filesystem and a means to communicate among developers, and when used in that sense, it’s extremely powerful and intuitive to use. And it can still be used as a version control system, much in the same way of using bazaar.

It’s blazing speed isn’t the only killer feature. By no means, however, is it “heavily optimised for the ‘I only apply patches’ development model, at the expense of ordinary development models.” It also supports centralised workflows just as well as it supports distributed approaches, and you can switch between them.

And now to help you out a bit, here are the git commands needed to do the same things you showed off in your post:

$ cd myproject
$ git init
$ editor .gitignore
$ git add .    # git rm ...

Are you following so far? Let’s branch before we commit. checkout -b is a shortcut to create a branch (git branch myproject-foo) and immediately switch to it (git checkout myproject-foo):

$ git checkout -b myproject-foo
$ git commit

Git keeps all branches within the same repository and lets you switch between them. Now, that is a killer feature: whether I’m versioning code or stuff like webpages, I often have external pointers to my code. For instance, I may have libfoo as a sibling of foo-ng and the latter refers to libfoo in the Makefile. If I wanted to try a new approach in libfoo, I’d have to change foo-ng’s Makefile to point to libfoo-newbranch instead, or juggle directories around. That sucks. With git, I just checkout a different branch in the same space:

$ git checkout master

And even better: if you don’t like it, you could just as well copy the repository to create a separate (remote) branch from which you can later pull or cherry-pick changes to the main branch:

$ git remote add foo ../myproject-foo
$ git fetch foo
$ git merge foo/master

Now back to your steps, and I’ll stick to the git way of branching. Note how git does not differentiate between pulling and merging in the sense that you do. If there are no local modifications, git just fast-forwards the branch with the commits on the master:

$ git merge myproject-foo

Even better, say you don’t want the last two commits:

$ git merge myproject-foo~2

Unless git can fast-forward, it also treats a merge as a single commit and the ancestry information allows you to inspect its component commits just like you would. gitk is another killer feature, which I believe bazaar copied from git, just like the bazaar folks adopted the concept of rebasing, which basically lets you rewrite history quite freely, another killer feature (which can be quite badly abused if you don’t know what you’re doing). And then there is git bisect and git-svn and git filter-branch and git describe and git stash and gitweb and, and, and…

So if I compare the git commands I used to the way you used bazaar, I fail to see much of a difference. Do you?

It is true that git comes with an astounding number of additional commands, most of which you never have to use, but which are available to the user. I don’t deny that their sheer abundance is overwhelming and confusing at first (a general rule for Git for beginners seems to be just to ignore ever command with a hyphen in it). But once you get out of the newbie stage (it took me about two weeks, the duration of Debconf7 to become an acquainted git user; in fact, David Nusinow placed me among the ranks of real git wizards Pierre and Keith before the conference was over)… arghs, I hate long remarks in parenthesis; once you leave the newbie stage, you’ll appreciate all these commands, which make it really easy to script complex tools with git, making any plugin architecture pretty obsolete.

Finally, I found myself trusting git way more than any other version control system I’ve tried simply because it’s so transparent and you are allowed to edit stuff under .git, which is mostly plan text files (and objects, which you don’t have to touch). It’s transparent, and it stays true to the Unix way of letting small tools do their jobs instead of the monolithic approach.

NP: Enchant: Tug of War

Update: Carl Worth has a similar beef with people thinking that Git is too complicated and has ported a chapter from a book on Mercurial to Git. It’s a good read.