A few days ago, Chris Maiorana wrote an article, The 10-Commit Rule: how git version control can improve writing quality, about how he uses Git and Emacs to regulate his writing workflow. The idea is to track how many changes he’s made to his text since the last commit and to stop and review his work when he reaches about 250 changes, deletions, or additions. The advantage of this system, he says, is that it keeps you from burning out in an initial burst of enthusiasm by forcing you to stop periodically and see where you are.
To help him with this, he has a mode line display that shows him how many changes he’s made since the last commit and how many commits he’s made today. It seems like a system that could be useful to many writers. The problem is, he didn’t explain how he got the numbers for his mode line display.
Now, however, he has a new post that explains how he generates that display. The TL;DR is that he interrogates Git to get both numbers. The number of commits is pretty easy, of course, but getting the number of changes is a bit trickier. Basically, he runs a script that does a git-diff and pipes the results through grep and wc to extract and count the “words” that have changed. To keep from running the script continuously, he caches the results and updates them only every 30 seconds.
I’m not sure I’d like using his exact system but I must admit that I do pretty much the same thing without the software assist. Every so often, I stop, reread and edit what I’ve written, and, if I remember, commit what I have so far. As any writer will tell you, there are as many writing methods as there are writers so whether Maiorana’s method works for you will be a matter of your preferences.