While this worked very well it does have one big drawback, it means I can’t put the themes and plugins I use into version control since they are inside the official svn checked out dirs.

Recently I’ve been switching to git and thought that switching the WordPress install to git would solve this problem. My first attempt was using the git-svn tool to convert the upstream subversion repo to a local git one. This would have enabled something very similar to what I was doing before with the “svn up” command, one git-svn command would have updated the code to the latest version.

The problem with that idea is that the WordPress repo contains over 10,000 revisions. Duplicating that via git-svn would have taken days and all I really need is the current version. I looked for a while to see if there was a way to limit the number of revisions copied but apparently there isn’t.

So, I fall back to searching the web and I came across Tracking WordPress using Git, which is pretty close to what I wanted. It is a little bit more work to do the updates that way but not that much.

What I need though is an internal dev version of the site on one branch, the live site on another and the upstream code on a third. Then I need to push the live branch to my web host, and I also need to be able to pull any emergency fixes I make direct on the live site back into my local git repos. Pushing changes with git is a little tricky since a push doesn’t update the checked out files, but I found a helpful blog entry A web focused git work-flow, which gives me exactly what I want.

The one remaining problem I have is I don’t completely understand how git merges work. The internal dev branch and the live branch have some differences I don’t want merged, paths etc. Whenever I try to merge the branches though it invariably automatically changes one branch to exactly match the other and auto-commits. I’m sure git can do this, merge some changes but not others without manual intervention each time but I haven’t worked out how yet.

Okay, after a bit more time working with this setup it seems the problem is bi-directional merges. Merging from dev to live works great right up until the point I do a merge from live to dev, at which point git seems to forget that there is some stuff that I don’t want merged next time I go from dev to live. Preventing the auto-commit makes this manageable though, to do this you (confusingly) need to specify “–no-commit –no-ff”. You’d think the no-commit would be enough on its own but apparently not.

So in my local copy I have 3 branches:

• master, the extracted WordPress tarball
• internal, my internal development/test site
• external, copy of the live site

I have the following settings set on my local git repo (private details redacted) to make pushing changes easier, I don’t have to remember any parameters for the git push command.

branch.internal.remote=origin
branch.internal.merge=refs/heads/internal
remote.external.url=ssh://$USER@$HOST/~/$GIT_PATH
remote.external.fetch=+refs/heads/*:refs/remotes/external/*
branch.external.merge=external
branch.external.remote=external

Then on my web host I have the bare git repo at $GIT_PATH that gets pushed to, and the actual live site. Both of those only have the external branch.

To update the live site all I need to do is make the changes on my local copy of the external branch, then run “git push”. This sends the changes up to the bare repo, which then automatically updates the live site.

Then when a new version WordPress gets released, what I will do is

1. Switch to the master branch.
2. Delete everything except the git dir.
3. Unpack the new files to replace the deleted ones.
4. Commit those to git and it will work out what has changed for that release.
5. Change to the other branches in turn and git merge from the master branch.

This should update me to the latest release without losing any of my local themes, plugins or mods.

I could go one step further and create “upstream” branches for each plugin I use in a similar manner to the main upstream WordPress branch. That would allow me to mod the plugins, and still upgrade them easily. I’m not going to do that though (yet) as I think it would be more trouble than it is worth.

This gives the huge of advantage of being able to identify the exact time a particular version of a program was created and thus make bug finding easier.

For compiled code this works really well, I just have the build process increment the number somehow. For interpreted code, such as python, however there is no build process. So how do I make sure the build number gets incremented every time? There is no way I would remember to increment it manually.

When I was using subversion I hacked something together using $LastChangedRevision$, so the build number was based on the most recent svn commit number. It worked well enough and I was happy.

Now however I’m switching to git, which doesn’t have keywords like CVS and Subversion so I’m a bit stumped. I tried hacking a script that auto-increments a number then runs a git commit, but not only is it logically flawed, but it relies on me remembering to run it rather than direct git commands which is never going to be reliable.

Maybe I could do something with the current date, but again that would rely on me running something. Probably repo hooks are the answer somehow but I’ve no idea how. The build no. itself needs to be stored in git so as to sync between computers. Can a git repo hook update a file then commit that update back to itself automatically (without an infinite recursion destroying the repo)?

Update (2009-04-05): I’ve worked out how to generate an auto-incrementing number via git hooks. Use the following script as a pre-commit hook (save as .git/hooks/pre-commit). It’s setup for python but it could easily be adapted for whatever language you need.

I was planning on setting subversion up on my web host, but I didn’t want to depend completely on that and mirroring subversion is non-trivial. So today I decided to have a go at git, which is much more suited to this sort of thing.

Thankfully there is svn import capability built in to git, so converting my guinea-pig project over was a doddle. Much more tricky was setting up all the syncing between the repos. I think I have the magic incantations down now though.

git remote add NAME URL
git config branch.master.remote NAME
git config branch.master.merge refs/heads/master

I understand the first line, the other two seem to be necessary, but I don’t know exactly what they do yet.

Also, it is better to run git pull than git push when dealing with a destination that has checked out files as push doesn’t update them whilst pull does.

One thing that is a little weird is I can’t push changes from the live site to the public repo, which is on the same server. But I can pull the changes down to my local machine then push back up to the public. Tried a couple of different ways but all failed for one reason of another.

Treating the other repo as local throws up permissions issues,

error: unable to create temporary sha1 filename

File exists

, due to the way webdav is setup on dreamhost. Treating it as remote (http) doesn’t work because the binary is compiled without curl support. Still, the round-trip method works well enough.

I also installed gitweb and pointed it at the publicly accessable repo, this was very easy contrary to all the web pages I read about it. Just name the config file gitweb_config.perl and tell it where to look for the git repos and away it went .

http://git.trollgod.org.uk/ is now available for anyone to view.