Blog - /Tech

I have chosen git as my version control system of choice, and am now beginning the process of migrating all of my projects over to it. One of the things that has been somewhat tricky is copying my stuff over to my webserver for public consumption. I could probably get by with copying the entire .git directory for each project and calling it <projectname>.git on the remote server (which I did successfully for my /etc and /home backups a couple of weeks ago), but I wanted to know the real way of doing it.

This is the best that I can come up with so far. I'd be interested to know how other people who are more familiar with git manage this.

• Log in to the webserver.
• cd public_html/git (or some such location)
• mkdir <projectname>.git
• cd <projectname>.git
• git --bare init
• For each branch in a project that I recently ran git-archimport on:
  • [on my computer] git checkout <branchname>
  • [on the webserver] git fetch ssh://my-computer.org/~/<project location>
  • cat FETCH-HEAD. Copy the SHA1 ID into the clipboard.
  • git update-ref refs/heads/<branchname> <pasted SHA1 ID>
• git update-server-info
• chmod a+x hooks/post-update
• rm -f FETCH-HEAD (not really needed, but I'm a pedant and like my directories clean of cruft)

Update

In retrospect, the much easier way of doing this would have been to do git push --all ssh://<name-of-webserver>/~/<path> on the local machine.

I'm really impressed with git-archimport. It is even able to handle seamlessly the case where I've changed the name of the repository each year (an awful practice, and one that should never have been recommended by the Arch manual). Best of all, unlike Mercurial's Arch import utility, it does not choke on missing repositories. If it can't find the repo, oh well — it just imports the base-0 patch that references the missing repo as a normal commit, rather than going further back into history. I need this, because I managed to lose my 2004 Arch repo.

It's hard to say exactly why I chose git over Mercurial. I think the git mailing list is what really won me over, much like how the Arch mailing list did in 2004. There's a lot of technical discussion, the occasional newbie who is helped, the occasional "celebrity" dropping by, and best of all, plenty of patches for interesting fixes and functionality flying across the ether. Another factor in the decision was noting how much improvement the documentation (manual pages, in particular) has seen compared to when I first checked out git last year. The recent (as of git 1.4-ish) emphasis on improving user friendliness was another tipping point. And the Google Tech Talk that Linus gave where he bashed SVN (deservedly!) won git some points with me :^) .