I gotta be honest with you: Sometimes I edit posts after publishing them. I fix typos and fix sentences that make no sense.

I’ve manually added Edit sections. But in the interest of automation and transparency, I just added a “Post History” link to all posts. The link goes to a GitHub page that shows every change I’ve made to that blog post.

Version Control

There’s an awesome tool called version control systems. If you haven’t heard about them, oh man, let me tell you. It makes it easier to iterate and collaborate on files. Notably, it helps with the draft-draft-v1-final-draft.doc problem.

Post History is powered by a version control system, git, and GitHub provides a pretty UI for git repositories.

post history v1

Here’s an example: I fixed a typo in my Talking LED post. You can click on the Post History button, and see all of the changes I’ve made to the Talking LED post, including this particular change.

Technical stuff

This blog is built in Jekyll. If you’re familiar with Jekyll, you might know you can host your Jekyll blog from GitHub using GitHub Pages.

_posts

But I’m not doing that. I don’t have a big reason. I just like my local Jekyll set up, and wasn’t ready to shuffle around all of my files or share my hacktastical deploy scripts with the world. Instead, only the posts are in the public repo. I did split out the _posts folder of my local private repo, so you get the behind-the-scenes of the last year of blog posts.

Adding the links was just a matter of using the page.path variable. It’s description even says “Example usage: Linking back to the page or post’s source on GitHub.”

So in the post template, I have

    <a href="https://github.com/jessstringham/blog/commits/master/{{page.path | remove_first: '_posts/'}}">Post History</a>

The awkward remove_first is there because I only committed the posts files.

Backlog

This was an easy way to get post history in an afternoon. But it’s not perfect. I worry that it’s inaccessible to folks who aren’t already familiar with git.