I've been streamlining my commit histories this way for several years now, and it's worth the effort. I do it pretty much the same way the author does (only I

I've been streamlining my commit histories this way for several years now, and it's worth the effort. I do it pretty much the same way the author does (only I use Emacs and Magit mostly). The reason I do it is because my work has to make sense to other people, and also to me six months later. So I think of my commit histories as stories that must tell people how my software got from point A to B, and tell them clearly. The chronological history of how I wrote some batch of code is just the first draft of the story. It's messy. It contains WIP commits, false starts, backtracking, and all sorts of cruft that tells more about the noise of software development (and when I stopped for dinner) than about how the software logically moved from one sensible point to another. Once I've got a chuck of work all figured out, all that noise has to go. It must be edited away before I publish the work upstream. Otherwise, I'm just weighing down everybody who has to understand the work later (including me).