Git endpoint for content in WordPress

A horrid, crazy idea: a Git endpoint for the content in my WordPress install.

One step back to the problem I’m trying to solve. More and more, I enjoy writing in Markdown with iA Writer. “Publishing” whatever document I’ve written generally involves hitting the Preview button in iA Writer, and then copy and pasting text into WordPress. Yes, the same workflow I’ve been preaching against for years.

I wish I could have a Git checkout of content in WordPress, make edits locally using my editor of choosing, commit, and push back to master. I’m aware of Jeykll and the other hipster “content management systems”, however I’m still an old-school content in a database kind of guy.

Git in my Subversion

Two weeks ago, I discovered magic: it’s possible to initialize a Git repo inside of Subversion (SVN).

Since the advent of Github as a leading collaboration platform, I’ve forever been trying to reconcile the Git to SVN workflow. Progress is faster in Git(hub) because it’s a far superior platform for fostering contributions. Seamless pull requests are much nicer than the multi-step process of creating and uploading patches. Distribution still happens in SVN, however, because many legacy deploy systems are coupled to it. Etsy took the leap of switching from SVN to Git, and essentially recommends against it. For the time being, we need to be able to live with both.

Two years ago (almost to the day), I wrote a post called “How to properly use Git with Subversion.” The thing is though — it wasn’t ever properly using Git with SVN. It was grinding the two tools together like a sixteen year-old learning to drive a stick. Furthermore, if I ever nuked my Git repo, I’d have to wait literally for hours to run git svn fetch on the repo. Boone has worked in a similar way for a while; I eventually gave up and started copying my files over manually when I needed to release. Mo does this with an rsync command.

A recent stroke of insight has changed my outlook on life, improved how I sleep, increased my libido, and generally made me a much happier developer. It’s this: Git and SVN can live side-by-side in the same directory. You just need to tell them to ignore each other.

This afternoon, for instance, I decided to spend a little bit of time on Edit Flow. I like to develop Edit Flow locally, keep the VIP shared plugins repo version on the bleeding edge, and occasionally release a version on Because I haven’t yet applied this “Git in my Subversion” approach to what’s in the latter two repos, let me now walk through what that looks like.

The first thing you should do is edit the “svn:ignore” property on your existing SVN repo. You can do so with:

svn propedit svn:ignore edit-flow

In this situation, I specifically want SVN to ignore two things: .git and .gitignore. Add those, save, and commit. SVN will now respect Git’s living style.

Next, change into your target directory and initialize a new Git repo. Running the following pulls my full remote project into the working directory:

git remote add -f origin

But, if I run git status, I’ll see that my local working files aren’t tracked by Git, I can’t checkout master or change branches, and Git is flummoxed. Don’t worry — as long as you’ve kept Git as master, and ported your SVN commits back to Git, you can run:

git checkout -f master

Boom, Git in my Subversion. Running git status I notice there’s a lot of .svn junk I don’t want tracked in my repo, so I create a .gitignore file to handle those (on trunk, I also ignore the wpcom-helper.php file we use for every community plugin to handle local action and filter modifications). The integration is complete.

With Git and SVN side-by-side, I can easily pull features I’ve developed locally into the VIP shared plugins repo, VIPs can create pull requests for community plugins, and I can push hotfixes discovered by usage back to the Git(hub) master project. It works well because Git and SVN are tracking the same files, but I don’t have to get them to live together harmoniously — they just ignore each other. Git-SVN be damned, this is much better.

What makes a good commit message

There’s a useful conversation happening in an internal Automattic P2 I thought I’d take the liberty to share.

From Mike:

Consider the audience when you write a commit message. What is that audience? It’s at least two groups of people:

  • Your coworkers: You’re telling everyone else what you did. Commit messages are one to many, asynchronous and textual. Sounds like email, so write the commit message like an email. The first line should be a descriptive subject. The next line should be blank (as a separator). Then comes the body of the message. Write everything as if you’re describing it to Nikolay.
  • Your future self: Think back on the times you were fixing something and needed to understand why an old commit was made. How often was the commit message useful? How often was it your own useless commit message? The commit message should say what the problem was (repro steps?), how you fixed it (briefly – the code itself gives more details), and why you changed what you did. That way the shiny pants people of the future have the information they need to decide if they can safely change your code.

From Matt:

I think as a company we need better commit messages. Very often in our messages we say what is happening but not the why, and most importantly the context of the change. I’m going to pick on this changeset, but you could really pick almost anything:

[link to changeset]

4 lines changed, with the message:

“Fixing incorrect $blogid variable, should be $blog_id.
Check if $current_blog is === false before trying to reset it.”

First a good thing: it’s a multi-line message, which is nice. Commit messages can use as many lines as you like, and be as verbose as you like.

However if I were to come across this changeset 3 years from now, say if I were debugging a similar area in the code, I’d have no idea why this change happened. The message might as well be blank, since it doesn’t really say anything I couldn’t tell in 2 seconds from looking at the diff. Some useful context would be:

  • What bug did this code cause? (This is most important.) Why change it?
  • Is there a relevant discussion, either on a P2 or in Trac?
  • Who was involved in the fix, IE who else would have context for this change either because they reported the bug or reviewed the fix.

From Lance:

Good commit messages are my gospel. The actual syntax should vary by context, though. For theme commits, for example, we always start with the theme name up front.

But, the goal of giving context and pointing to related items is key.

I personally don’t think long commit messages are better. Instead, point to a Trac ticket or P2 post with all the gory details.

Musings on Git and Github

Using Github has changed, and continues to change, my development practices, by making me think more about audience and reuse (notions that are familiar to teachers of writing), encouraging the “release early and often” mantra (since all my stuff is public anyway more or less as soon as I write it), and orienting me toward collaboration by default, rather than solo coding. All these changes are highly laudable, leading to better product, and making my work more fun.

Boone Gorges — Musings on Git and Github.