Re: [RFC] input.cpp: Remove use of strncat(3)

[Dave Kemper]

I have no opinion about this particular change, but to address this
general point:

On 12/5/22, Larry McVoy <lm@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.)