The Flow of Consciousness

Using Subversion to manage my WordPress installation was convenient and mindless. Whenever there was a new release of the blog software, I could hop to a terminal, back up my filesystem and database, and run svn sw http://svn.automattic.com/wordpress/tags/(new.version.number).

This worked great all through WordPress 2.x. However, when I tried to switch from 2.9.2 to 3.0, things broke. As in, “white screen with PHP failure message” broken. I hit the dreaded is_multisite error because something didn’t come in right or I’d accidentally modified something or maybe even the tag was out of date.

Regardless, I decided that in order to fix the problem, I needed to wipe out every file or directory which began with wp in my /blog directory and copy over from a fresh download of the package.

I mindlessly did this, then realized: “Oh crap, now I can’t upgrade with Subversion any more.”

I queried Twitter, asking So I went and deleted all of the .svn directories in my wp install. Is there a way I can put it back on svn without having to recopy stuff?. @steveklabnik quickly replied, jokingly, @colindean yeah, you just run ‘git init .’ .

A troubleshooting conversation ensued, and then I found that WordPress maintains a GitHub repository.

Then it hit me: maintaining my WordPress installation with Subversion is so…WordPress 2.0. I’m on WordPress 3.0 now, it’s time to embrace modern distributed version control systems and use Git!

Steve, being an intrepid Rubyist friend and Git user, suggested how I could version my existing blog directory and add a git remote, then fetch and rebase, thereby syncronizing my local installation with an easy to use versioning system!

However, because it’s a development repository without any “tags”, I’ll have to remember to look for a specific commit whenever I upgrade.

I changed things up a bit and corrected order of things. Here’s what I did to get it working. Note that I’m a git newb and very open to suggestions if there’s a more succinct or overall better way to do this.

Note that I used git protocol for the repository (Github’s HTTP git seems to have problems completing transfers to my server).

Initialize the local repo and add what you have already:

git init
git add .
git commit

Add the remote, fetch and rebase:

git remote add gh git://github.com/wordpress/wordpress.git
git fetch gh
git rebase gh/master

At this point, I was informed that I had some files in wp-content/cache which needed to be deleted/updated. A quick git status showed that I’d versioned these cache files. Oops! You’ll have to do git rm <filename> for each of those, or just do git rm wp-content/cache.

Next, I added a few directories to .gitignore using my text editor of choice:

wp-content/cache/*
wp-content/uploads/*
wp-content/plugins/*
wp-content/themes/*

Then, I needed to merge in the 3.0 commit.

git merge 7cee95b6bba8bc867023ae0831e7538a8419a9f5

There were a few conflicts, but all were easily resolved. Use git add on each file needing resolved, then git commmit to finalize your changes. Once you commit, you’ll be up-to-date and merged with that version.

I’ll update this post or make another when the next release of WordPress is out to report how well the actual upgrade goes.