So, I wrote a tiny little program to help facilitate using git and WordPress together through the XMLRPC API, and it’s helped me write… well, if not more than at least less painfully.

Setting Up

Assuming that your blog is set up at http://www.yourblog.com (you can create an account at wordpress.com to test this out), all you’ll need to do is:

-- make a directory for the blog
mkdir blog
chdir blog
 
-- download everything
python wp.py download --user=yourname --password=yourpass --url=http://www.yourblog.com/xmlrpc.php
(wait a bit)
git init
git add .
git commit -m "first version"
 
-- now set up so we don't have to specify --user, --password, and --url every time (optional)
git wp config wp.url http://www.yourblog.com/xmlrpc.php
git wp config wp.user yourname
git wp config wp.password yourpass

The files are downloaded in the appropriate YYYY/MM directories, with the draft directory being used for all of your unpublished drafts.

All the drafts are stored in plain text, but you’ll see some lines starting with periods — these are various WordPress variables that are associated with the file. You can change them, as well; for example, to change the title of the post, just change the line that begins with “.title”.

Seeing What’s Different

You can use the status command to see differences between the local file system and your blog.

python wp.py status

Updating From The Blog

If you’ve made changes through the web interface and you’d like to bring them down, you don’t have to download everything again, but can instead just update.

python wp.py update

Posting/Editing

If you’d like to edit a post, just edit it, and then use wp post to push it back to the blog:

python wp.py post changed-file

To create a new post, just create a new file in the draft folder — I like to specify the .title and .wp_slug parameters, as well — and then post it. You can also publish it by changing the .post_status line from draft to publish.

Gotchas

While this program requires git, it doesn’t automatically check anything in — so you’ll need to make sure you do git add / git commit or whatnot as necessary.

There are also some gotchas due to the fact that the filename can change on you. There are cases where the filename that will be brought down is different then the one that you send up:

• You post a file without a .title or .wp_slug line
• You post a file with a different file name than the slug that is generated (i.e., “my-first-draft” when the title is actually “my final draft”)
• Something moves from “draft” to “publish”

When you see a message of the form “changed: fn1 -> fn2″, it means that a rename has occurred, and you’ll need to do the git rm/git add or git mv by hand.

Source

Bob checks it out, makes changes 0..2, and does regular pulls: A -- B -- 0 -- 1 -- C -- 2 -- D

Now, Alice pulls Bob’s stuff: she has A -- B -- C -- D -- (0 + 1 + 2)

Alice pulls from another developer: A -- B -- C -- D -- (0 + 1 + 2) -- E

Bob’s patch is bad! How did it get through the audits and QA and unit tests? No matter, revert it. Alice now has:

(Note that Alice can’t rebase Bob’s changes out of the history because other developers are pulling from her).

Bob sees that his commits didn’t work, is properly chastened, and makes a fix titled “3″.

Now, see the problem:

• If Bob pulls from Alice, he’ll either get a merge conflict if he’s made changes, or his stuff will get deleted out of his repo (!)
• If Alice pulls from Bob, then she’ll have problems — her mainline thinks that it’s already taken Bob’s changes, but now he’s trying to change a deleted file.

So it looks like Git is in a situation where someone or the other (or both) are going to have to do a painful merge conflict resolution. There must be a better way of reverting a patch?

Update 3/20/2009: The word from Linus on this. He says that when you unrevert the merge that you always need to revert the revert, rather than trying to apply it again.