Skip to content

Content as files, and why we stopped

1 min read The maintainers

  • content
  • process
A folder of markdown files and a database table holding the same posts
Photo by Maksym Kaharlytskyi on Unsplash

What files were good at

A post that lived in git was reviewed the way a schema change is: a diff, a reviewer, and someone who could say no. Every edit was a commit with a name and a reason attached. There was no second system to back up or patch.

Why we stopped anyway

Every one of those properties is worth something to the people who write the code, and nothing at all to the person who needs a sentence changed on a Thursday. Fixing a typo cost a pull request, a review and a deploy — so typos stayed. The corpus was correct and slightly stale, permanently.

Getting the history back

The strongest argument for files was that a CMS's revision history is a feature someone can turn off, while git history is simply the default.

That one we took seriously. Versions here are written by a database trigger, not by the editor: every write to a document appends a row carrying the author, whatever made the write — the admin UI, a migration, a psql session. Two rules make that table reject updates and deletes outright. It is not a setting, and there is no screen on which to disable it.

What we did give up is the reviewer. A published change goes live immediately, with no diff and nobody to say no. That is a real loss, and the honest trade for a typo that gets fixed the day someone notices it.