Here's why I care about that stuff: I work at a place that has some code in production that's over ten years old, and which no one now working there wrote. We

Here's why I care about that stuff: I work at a place that has some code in production that's over ten years old, and which no one now working there wrote. We have many more discrete systems than developers. The repo history, including its comments (actually currently in SVN, where rebasing isn't a ready option), is a major tool for interpreting the intent of authors now gone (or who now don't remember writing it, something I'm guilty of, certainly). The clean narrative you are asking for is there, in tickets and internal wiki pages. The actual history of commits helps tell a different story, about whether it was intentional that line 493 was omitted because of the effect on another part of the code, or whether it being missing is a merge artifact or other tool screwup. We're about to switch to git, and one of the things I worry about is that newer developers steeped in the ways of rebasing will come on board and "clean up" their commits to hide informative early missteps and paper over the cracks and seams of their work with single commit messages per feature which afford no understanding of the difficulties involved in developing it.