Martin (arp242) recently inherited a legacy project. Before he even read the code, he ran a single command:
git log --no-merges --format=format:'%b' | sed '/^$/d' | wc -lThe result: 295. Over 13 years, every commit message in the project added up to 295 lines total. After stripping out dependabot auto-commits, “revert commit,” and “fix typo,” 167 lines remained. Roughly one line per month.
No documentation. Almost no comments. And the previous developer’s three-week handoff period matched the commit log in quality. “I have never understood Jack Bauer’s willingness to use extreme measures to extract information more than I do now,” Martin wrote. “I regret not trying it.”
Two Sides of the Fence
Chesterton’s Fence has circulated in software engineering for years: you see a strange piece of code, you want to delete it, but first — figure out why it’s there. It might be guarding against a danger you haven’t recognized. That’s the positive side. As G.K. Chesterton originally wrote, before a reformer tears down a fence, they must be able to answer “why was it built here.”
Martin gives us the other side — Chesterton’s Middle Finger.
“Yes, we did all these weird things, and we’re not going to tell anyone why. Fuck you.”
A fence’s meaning depends on context. When context evaporates along with the commit messages, comments, and documentation, the fence stops being protection and becomes a curse. The next developer faces an unmarked ruin: a pile of inexplicable junk, leaving them two choices — months of archaeology, or the gamble of tearing it down.
Three Kinds of Toxic Commits
Martin never systematized this, but his description sketches three of the most destructive commit patterns:
“fix page A” — the hollow title. Even for large-scale changes, the commit title is just “fix page A.” The title conveys nothing. The body is empty. Later developers have to reverse-engineer intent by diffing line by line — accuracy roughly equivalent to reading bones.
The WIP commit — abandoned midstream. Unfinished refactoring scattered through the codebase. Carcasses of old features never cleaned up. Features that were added but never linked to any page, never used by any user, sitting silently in the depths of the code. They’re not bugs, but they’re worse than bugs — at least someone reports bugs.
The “not needed” — Chesterton’s Gap. Martin introduces a symmetric concept: if Chesterton’s Fence is “built a wall and never told you why,” Chesterton’s Gap is “built a wall where none was needed” — adding abstraction layers nobody asked for, over-engineering, pre-designing for a future requirement that never materializes.
These three patterns together constitute an archaeological disaster: successors must not only understand what the code does, but reconstruct why their predecessors did it, and what they intended to do.
Three Questions
Martin offers a down-to-earth commit message framework — three questions:
- What did you change?
- Why did you change it?
- Why is this a good solution?
“Implement new feature X” suffices sometimes, but most of the time there’s always something to say — even just explaining a parameter choice, the origin of a boundary condition, an alternative you rejected.
You don’t need beautiful English. You don’t need a philosophical treatise. Forgetting to mention some detail is acceptable (though including it is better). The bottom line: something is enough. Any half-hearted attempt is infinitely better than a blank.
Martin’s judgment is blunt: “Writing commit messages is not an optional extra. It’s part of the job. Not doing it is not completing the work you’re being paid for.”
The Lobsters Consensus
The article scored 106 points on Lobsters, with virtually no controversy in the comments. One user wrote: “I spent five years traveling the world fixing codebases like this. I carry Working Effectively with Legacy Code with me to sleep.”
Another user, david_chisnall, hit on the core value of code review: “The greatest benefit of code review is that it forces you to write down all the unspoken context. Whatever you can’t explain clearly, whatever the reviewer doesn’t understand — it all has to go into the comments.”
A recurring scenario: inheriting the codebase of a departed colleague. When you can’t ask anyone questions, the commit log is your last information source. If it’s empty, you’re not facing code — you’re facing an archaeological site where every inscription was deliberately erased.
Why This Matters More Than Ever
AI coding tools (Codex, Claude Code, Copilot) are accelerating code production by an order of magnitude, but commit messages don’t auto-generate — or rather, the auto-generated ones (“Add files via upload,” “Update code”) are worse than a blank, because they create the illusion of documentation.
A 13-year project with 295 lines of commit messages will become more common, not less, in the AI-assisted era. Because producing code is faster than writing comments, and AI currently won’t think “I should probably explain why I chose this data structure over that one” on your behalf.
Martin’s closing line: “If you write nothing, you’re giving the middle finger to everyone who comes after you.” The metaphor is crude, but accurate. A commit message isn’t a memo to yourself — it’s for you three years from now, for the colleague who inherits your work, for the person pulled into an on-call at midnight to track down a regression.
This article draws on publicly available information and community discussions. If you have deeper first-hand experience with this topic, corrections and additions are welcome.