Fri, 09 Sep 2005

Git: An Experience in Pain

I had the opportunity to try to use git today. Having used bzr and mercurial and been favourably impressed, I guess my expectations were fairly high.

As it turns out, far too high. There's no clean way to get git (apt-get would have been nice, but a tarball to compile would have been fine too), so was given Debian packages by Stephen. Set up an rsync repository to hold the .hg files. You can't use "git-push-script" on that empty dir, so rsync the original files across. Then you to use "git-pull-script" you have to add .hg to the URL: my mistake, should have just rsync'ed that dir.

Now try to push. The man page for "git-push-script" says what you'd expect, so you do "git-push-script rsync://machine/mydir/.hg". "Cannot push to rsync://machine/mydir/.hg". Er, ok, why?

AFAICT, grovelling through the scripts, the man page lies: it doesn't actually support push over rsync. Hell, maybe it doesn't really support push at all; seems you need to rsync upstream manually. Of course, doing this means you can't have more than one user pushing to a repository at a time, which might be fine for Linux, but simply won't work with any kind of core team.

Now I start to understand why the Xen guys chose Mercurial . Linus seems proud of the fact that he didn't write an SCM, just a content-addressable-filesystem, but there's a lot more required to turn that into a usable system than a handful of scripts.

So kudos for Matt Mackall for actually writing a system which is usable; it makes git look like a half-finished school project.

[/tech] permanent link