Free Software programmer
Subscribe This blog existed before my current employment, and obviously reflects my own opinions and not theirs. This work is licensed under a Creative Commons Attribution 2.1 Australia License.
Categories of this blog:
Older issues: |
Fri, 09 Sep 2005Git: An Experience in PainI 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 |