Geek on Two Wheels

In any sane web development setup, at some point, content must be propagated from the development environment to the production one. scp and sftp are some of the favourites: git is mine.

By using the working directory of a git repository as your live website, you gain several notable advantages over manual uploading:

• The website itself doubles as your primary, authoritative repository.
• It becomes possible to apply all of git’s features on your production website. Things such as emergency roll-backs become trivial, dependencies permitting.
• No need to think about what actually needs to be uploaded and what doesn’t on an update: just git push.

Now, the last point needs some explanation. When blobs are pushed from one repository to another, by default, the working directory of the remote repository is untouched.  The reasons for this should be obvious, but, in this case, modifying the working directory is precisely the desired behaviour.  To have git update the working directory every time it receives an update, we use the post-update hook.  Here is a trivial example:

#!/bin/sh
# Update from repo
cd ..
unset GIT_DIR
exec git reset --hard

1. git runs its hooks from inside the .git directory. Not all git commands work from this location, so first we get out from it.
2. The GIT_DIR environment variable is set to “.” when executing hooks. This will cause issues as we are no longer in .git, and must be unset.
3. Finally, git reset --hard is ran to reset the working directory to match the current branch’s data in the repository.

Of course, there are tons more things you can do using the hook, as you have full shell scripting capabilities.  See git help hooks for information on all the available hooks.

As a departing note, remember to set the permission on the .git directory so that you are not leaking sensitive information.  Unless, of course, you want everybody and anybody to be able to checkout the complete revision history of your website.

Whether you’re just learning git or want to learn a new trick or two, git ready is a pretty good place to go.  The listing of articles by task goal instead of command explanation should be especially helpful to the newbies.

I’ve finally installed cgit onto my public git repository.

Of the branches in xf86-video-radeonhd, lut and r5xx_pm are mine, while master is simply a copy of upstream. I don’t recommend you clone my repository: clone upstream, then pull a branch instead. lut is complete, and waiting to be pulled upstream, and r5xx_pm is on-hold indefinitely at the moment.

I will make my OpenID server implementation available here as well, once I put it under source control. (No, it’s not, yet. Yes, stupid move.)

More projects to follow, hopefully.

Hackers that know me personally may have noticed my praising of Git. Today, I came across an article talking about what the author calls the Tangled Working Copy Problem, and how git copes with it. The article is a good read, regardless of your source code management taste.

Aside from highlighting some useful features that are afforded by distributed VCSs, the article also exposes how weak Subversion can sometimes be, no matter how magnificent it may seem compared to CVS.

If you haven’t made the leap and embraced the distributed VCS model, I highly recommend at least trying it. Git, Mercurial, Bazaar, whatever: just pick one up, and do some development with it. You may never go back to subversion again.