I didn’t like upgrading wodpress much. Everytime I did it, I needed to re-apply all my little tweaks to the new wordpress. It took too much time.
I tried to diff -uNr
on the current version I was running and the newer version and then applying the resulting diff to the current version, but it seems wordpress has been backporting changes so I got conflicts, quite a lot of them.
Because I was quite tired of porting my changes, I’ve tried git, the Source Code Managment tool used by the linux kernel, to do it for me:
I did this all in the parent directory of the root of blog.w-nz.com. This folder contains:
htdocs
current installation (2.1.2)2.1.2
the unmodified wordpress2.2.0
the new wordpress I want to upgrade to
First, I created an empty git repository:
mkdir git; cd git; git init-db; cd ..
Then I copied over the unmodified version of wordpress I was running, and commited them:
cp 2.1.2/* git -R
cd git
git add *
git commit -a -s
cd ..
Then I copied over my current installation:
cp htdocs/* git -R
git status # lets see what changed
There are lots of files like uploads I want git to ignore, so I edit .gitignore
to make git ignore them. There weren’t any files I added though, otherwise I’d had to run git add
to let git know.
And let commit my changes:
git commit -a -s
Now, lets go back to the original commit — the clean 2.1.2 wordpress — and start a branch from there:
git checkout HEAD^ # HEAD^ means parent commit of HEAD: the previous commit
git checkout -b tmp # create a new branch tmp from here
Now I’m in a branch without my own changes, which was forked from the master branch. Lets apply the new wordpress on this branch:
cd ..
cp 2.2.0/* git -R
cd git
git status # see what changed
git-status
showed me that there are a few new files in wordpress 2.2.0, I git-add
-ed all of these new files. And then committed it all:
git commit -a -s
Now I’ve got two branches:
master
which contains wordpress 2.1.2 with my own changes on top as a committmp
which is forked from the wordpress 2.1.2 from the master branch without my own changes but with the 2.2.0 changes on top
What I want to do is to reapply the 2.2.0 changes on top of my current changes’ commit instead of on top of the 2.1.2 commit. To do this, git has a very powerfull util called git-rebase
:
git rebase master
This will search down the tree until the point where the current branch (tmp) forked from the target branch (master). Then it will re-apply all commits in between on the latest commit of the target branch.
Just like if I’d use diff/patch I get a merge conflict. git rebase
lets me know this and git status
shows me which one are these. The one little difference with the diff/patch approach is, that there are way less merge conflicts (git is smarter) and that the merge conflict are way easier to identify and they’re inline in the original files. Not to mention that when I would have fucked up I’d always have a way back.
After I fixed the merge conflict, I git update-index
each conflicted file (to tell git it’s resolved) and git rebase --continue
-ed.
Now I’ve got my updated wordpress in the git
folder. Then I backuped the current, copied over from git and visited wp-admin/upgrade.php
and I’m done :).
By the way: “I didn’t say Subversion doesn’t work. Subversion users are just ugly and stupid.” — Linus on this Google tech talk.
Sidenote, I switched from Hashcash to Akismet. Hashcash didn’t work anymore and Akismet theoretically should be the best solution because it isn’t based on security by obscurity.
I know this post is a little out of date now, but looks like it should still work with current versions of git and wordpress. One exception is that you’ll need to use “git checkout -b tmp HEAD^” instead of doing the checkout and the branch in two steps. I don’t know if that ever worked in two commands like you used there… It didn’t for me though!
The other issue I see is that if a new version of wordpress removed files that were present in the old version, the steps you describe won’t get rid of the old files. To prevent that, I think that deleting all the files before copying the new version into the tmp dir should work.
You’re probably right. Obviously you indeed want to check for stray files. Some might be usefull to keep around like uploaded images and alike. A look at
git status
is always helpful.If you want to clean untracked files from your repo then
git clean
(-f
) is your friend.