[TeMPOraL]

There is a third type of coder: one doing commits with single, obvious, minimal purpose, that still sometimes end up being +8,298, -1,943 - but with a sensible, detailed message explaining what's being done and why.

This happens in environments where it takes hours for CI to let your change pass, making small commits prohibitively expensive in terms of time and infrastructure.

(And yes, I know the answer is: make it so CI that's part of review takes minutes, not hours.)

[chrismorgan]

And then there are the cases where the diff is a single line, but the commit message over a hundred lines because the change (or more likely its justification) is not obvious.

[TeMPOraL]

That too.

I've never seen a 1:100 code to commit message lines ratio so far, but I've seen a few 2-3 line changes with a paragraph or two long explanations. I cherish those. Same if the explanation is in a comment. In fact, if I spot something like this, I tend to praise it publicly on the team chat.

I had one case where a single weird line added much earlier messed up a seemingly unrelated piece of code I've been developing. It took me a while to figure out that something is emitting compiler flags that, with surgical precision, prevent the very thing I was attempting - and then find it nested deep in the build configuration. At that point I wanted to strangle the person who put it there - but a paragraph of commentary attached to that line, plus some extra context in the commit message, made me change my reaction to "oh. OH. I see the point now.", and I ended up commending the author instead.

[chrismorgan]

I’ve done 150 lines on what I think was a two-line diff before, and >50 on a one-line diff a few times. But I am known for my verbose commit messages. (After two years working on a twenty-odd-year-old commercial code base that had had a dozen or so people working on it constantly, I had around two thirds of the longest commit messages. My longest was something like 400 lines, but most of that was a list of affected class names or similar, on a diff of tens of thousands of lines from a mostly-automated refactoring.)

I’ve definitely also added multiple paragraphs of in-code comments to an otherwise-single-character change, where it’s an ongoing consideration rather than something that can reasonably be left in a commit message alone. Then my commit messages gets to be brief, directing you to read the added comment instead.

[avgcorrection]

See for example commits by Jeff King on the Git project. :) It’s impossible to infer those messages from the diffs alone.