intertwingly

Aristotle Pagaltzis: Since I started using git, I noticed that I use version control for many more things than I would in the days of using Subversion. It seemed to be a lot easier to put everything under version control, but for a while, it was merely a feeling whose reasons I found hard to fathom, then hard to articulate. After recently reviewing the ceremony required by Subversion to establish version control for something, the reason stood out to me clearly: Subversion makes the mental overhead of creating a repository very much greater than any DVCS.

Me too, and I think it is more than that.  Whenever I find myself updating a script I wrote months or even years ago, these days my first step is to do a git init.  Why?  Because I like being able to do things like diff and a revert (despite the fact that git spells revert c-h-e-c-k-o-u-t), so git scratches that itch.

It also is lightning fast, and speed is a feature.

Once I complete the change, it often occurs to me that this particular script is valuable enough to me to warrant an off-site backup.  That too is a matter of a minute or two, to any host that supports ssh.  Git takes care of all of the details of rsync’ing, and there never is any fear of doing the command in the wrong order and wiping out your backup.  And again, git is super fast.

I’m now starting to explore the “hooks” that can be exploited.  post-update, in paticular, is a simple script that you can add commands to that will be executed on the destination at the completion of a push operation.  It can do things like touch tmp/restart.txt.  Anything output to stderr shows back up on the client, so feedback is as simple as:

echo '--> Server restarted' >&2

One thing to watch out for: commands need to be placed before the exec git-update-server-info as scripts never return from an exec.  Either that or replace exec with source.