A Small Step

As I said in WhileDo, after the automated blog post description has been implemented - and it has been implemented as is proven by this mastodon post^[1] - I was going to tackle the much bigger task of implementing a versioning system for blog posts. What do I mean by that?

It allows readers to switch between versions of a blog article. I want to have this, since this blog is frequently changing/updating older posts and I want to have my cake and eat it, too: Allow for older/original versions of posts to be available as well as have the freedom to update posts as I see fit. The good thing is that I use git to version control my blog. The bad thing is, that I only have so much history to work with, because 1.) I had this blog running on a hosting platform for years and 2. I recently moved to a monorepo setup with a brand new git repo. This means that the history will only include versions starting in the end of august 2025. But that's fine.

So here's the rough idea:

• Write a script that adds all commit hashes that pertain to a certain blogpost to the frontmatter
• Read these hashes and - somehow - extract these older versions from the git history on building the site
• Build UI that allows switching from one version to another

Before I can even write a script, I need to figure out how I can collect commits that include changes to a blog post. It seems a simple git log --follow -- filename ought to do it:

git log --pretty=oneline --follow -- apps/blog/content/blog/2025/10/03/Write\ Like\ You\'re\ Ron\ Jeffries.md
9402b41142602cd4a5f658646cf26944d7c7c04e (HEAD -> main, origin/main, origin/HEAD) Commit by obsidan-git
192cbd19e13b9d891ec19077c131c4b53aa69fd1 Fix BuildInPublic tag
a55686c28205d910943a15f7d2e1a4873cdd6b5d Commit by obsidan-git

Not bad! So we would do that for all files in a given folder recursively. And save those hashes to the files under a versions frontmatter property.

And how do we get git to display the contents pertaining to a particular hash? Like so:

git show a55686c28205d910943a15f7d2e1a4873cdd6b5d:apps/blog/content/blog/2025/10/03/Write\ Like\ You\'re\ Ron\ Jeffries.md

But probably better for our purposes is the second solution given there:

git cat-file -p a55686c28205d910943a15f7d2e1a4873cdd6b5d:apps/blog/content/blog/2025/10/03/Write\ Like\ You\'re\ Ron\ Jeffries.md

As this just prints out the old version instead of piping it to less. Very cool. So we would use git log --follow to build up the list hashes and then instruct eleventy to shell out to git cat-file -p to retrieve the old versions listed? Probably! I imagine that we could build up a collection of these files and make them available for a build in that way. I can see some troubling edge cases we have to think about:

1. What about commits that have broken articles in them, f.x. that don't render properly because of syntax errors?
2. What about commits that include versions I'd rather not share?
3. What about features like my fav system? That should probably only count for the current article? It kind of has to at the moment, as the permalink is the unique id in the kv. This means though that I have to render those articles slightly differently.
4. What about the multiplied effort eleventy has to go trough to render these posts? Even if only some articles have versions, let's say 300 have 2 versions and the current one. They would kinda count as 900 articles all of a sudden! Maybe that's fine. I don't know. We'll see.

1-2 means we need to able to exclude broken/private versions. 3 means we need to make clear that you're looking at an old version. 4 means we might have super long build times at some point, I might've to not render images for old versions to shave off some time or maybe generate versions at runtime. We'll see.

I guess this is where I stop today. About 40 minutes of thinking about the thing. It was fruitful as ever even no code was written.

• ← Previous
  DailyDogo 1409 🐶
• Next →
  DailyDogo 1410 🐶