Or rather, I do use version control when I’m writing, and it isn’t helpful.
I’m currently studying a PhD, and I have around 113k words of notes in a git repository. I also have countless words of notes in a Zotero database and a Remarkable tablet. I don’t particularly miss git when I’m not storing notes in my repository.
A lot of the commit messages in that repository aren’t particularly informative. “Update literature search”, “meeting notes from today”, “meeting notes”, “rewrite introduction”. So unlike in software, where I have changes like “create the ubiquitous documents folder if it doesn’t already exist” and “fix type mismatch in document delegate conformance”, I don’t really have atomic changes in long-form writing.
Indeed, that’s not how I write. I usually set out either to produce an argument, or to improve an existing one. Not to add a specific point that I hadn’t thought of before, not to improve layout or structure in any specific way, not to fix particular problems. So I’m not “adding features” or “fixing bugs” in the same atomic way that I would in software, and don’t end up with a revision history comprising multiple atomic commits.
Some of my articles—this one included—have no checkpoints in their history at all. Others, including posts on De Programmatica Ipsum and journal articles, have a dozen or more checkpoints, but only because I “saved a draft” when I stepped away from the computer, not because there were meaningful atomic increments. I would never revert a change in an article when I’m writing, I’d always fix forward. I’d never introduce a new idea on a branch, there’s always a linear flow.
For my code projects I have written commit messages that have been dozens of paragraphs long.
But when writing my book I found that a good chunk of my commit messages are exactly as you describe. If anything it sometimes feels like little more than a dirt cheap backup system.
One particular difficult concept I rewrote more than a dozen times. That is the one of the only times I went back looking at previous versions.
The one feature in my writing that I do use regularly is git add -p. It lets me review what I have changed. Just like with code this lets me not include accidental changes, or WIP/notes that didn’t belong. And it also caused me to read over my writing one more time which has caused countless small improvements.
Commit messages explain what the code is doing, but in my writing if I need a good commit message that often signals I did a bad job of writing and it should be re-written.