I have no opinion about this particular change, but to address this general point:
On 12/5/22, Larry McVoy <l...@mcvoy.com> wrote: > I used to run a company that did source management tools and we strongly > discouraged these sorts of "clean ups" because they change the author > of that line of code. Our system made it painless to go from a line of > code to the commit that added that line of code. Which, if it goes back > to the original commit, is super pleasant for debugging. If I have go > to your commit, then realize, oh, it used to be the commit before that > and so on, it takes longer to figure out the bug. ... > So there is real value to asking yourself "Am I actually fixing a real > bug?" While I'm a big proponent of the "if it ain't broke, don't fix it" school of thought, just in my limited trawling of groff's "git blame," this already seems like a lost cause. Especially recently, there's a lot of churn in the source code. Looking at the change log of the file under discussion, of the past 33 commits, 14 were changes to stderr output (usage, diagnostics, etc.), 13 were code refactoring, and 6 were bug fixes. If that's representative (which I bet it roughly is, as input.cpp is pretty central to groff), over 1/3 of groff's code changes do not affect its operation. > And it is groff, not some mission critical database. If I were in > charge, I veto these sorts of commits and fix the problems if/when > they arise and have a cleaner history. That knife cuts both ways: because it's not mission critical, the time it takes to debug problems is less important, so there needn't be any particular effort to minimize the amount of changes in the history. (If such effort even has the effect of speeding up debugging: as Alex points out in his reply, whatever the cost of making a useful refactoring commit, there is also a cost associated with NOT making that change, in terms of code readability or comprehensibility. These can also be impediments to debugging.)
