After seeing a post on the github blog about David Baldwin using github as his blog I got to thinking about how much easier it would be to create my markdown posts offline and then commit them to some repository and have them show up as blog entries.

The comments for the github entry point out a number of people using various solutions to achieve an effect similar to what I want however I am somewhat loathe to give up on a web interface in general and Wordpress in particular. But this did get me thinking, what about a post-commit hook so after every commit a script examines the changed files and creates or edits posts as necessary. Google didn’t turn up much of anything in the way of making this happen and so I started thinking about how I would write my own solution.

As of right now I’m just in the planning stages but I did realize it would have to be a pre-commit hook on account of wanting to track the post id somewhere and the most logical place seems to be as some meta information at the top of the post. Currently I have the pre-commit hook reading the information I need to send about the post out of the file, the next step will be to figure out creating an XML object to send to the xmlrpc.php file of my Wordpress installation. In addition to dealing with hooks and xmlrpc¹ I’m writing the script using Perl in order to get some hands on experience with it.

I’ll admit I’m not 100% sure I can make the script do what I want it to do but I’m certainly going to give it a shot because looking at the solutions eluded to in the comments of the post on github there doesn’t look to be a solution to satisfy me yet.

My initial planning has the username, password and xmlrpc url being stored as config options via git config username|password|xmlrpc while post related information is stored in the actual post file. I think the most likely hang up will be modifying the file which is about to be committed (by adding the post id) because I believe I’d actually have to create the post via xmlrpc, write the response into the file, stop the commit, add the post file back to the index and re-commit. There may also be a problem with the way xmlrpc expects the categories.² Time will tell.

As I wrote earlier I’ve been using git at work via git-svn with a Subversion repository. At first I thought this was brilliant and would solve my continuous branching and merging ails. As it turns out I wasn’t entirely correct¹.

See, while I like git and how easy it makes branching and merging git-svn doesn’t play quite as nicely² with branches and merges and rebases as I hoped. Maybe part of my problem is that I needed to keep some of the git branches (which didn’t originate as SVN branches) in sync across a couple computers. In order to do this I set up my server³ to store the git repository related to my work’s SVN repository. The problem with this is every time I fetched and merged from the repository hosted on my server and then did a git svn rebase I wound up having to go through and ‘resolve’ all the conflicts coming from a the svn commits pulled in from the rebase on another computer. Not only was this incredibly annoying but it also meant there was the distinct possibility of winding up with double commits when I next did a git svn dcommit.

I’m not too ashamed to admit I had this problem a couple of times before I figured out I needed to use one branch to keep everything synced up with SVN (site_trunk in my case) and another, or several others as the case may be, to do the development work in. This way I use git svn rebase and git svn dcommit from only the place which is following the SVN branch and do merges as necessary to keep other branches up to date with work which has been done. As a result the ’svn branch’ is only used to contact and deal with the SVN repository all other work is done elsewhere. Since I adopted this process I have had no problems with rebasing or double commits.

If you need to install all the software to compile the git manpages check out wincent.com: Setting up the Git documentation build chain on Mac OS X Leopard.

If the only concern is recompiling the man pages…

make prefix=/usr/local doc
sudo make prefix=/usr/local install-doc