undefined | Better HN

0 pointsTeMPOraL3y ago0 comments

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.)

0 comments

chrismorgan3y ago

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.

TeMPOraLOP3y ago

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.

chrismorgan3y ago

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.

avgcorrection3y ago

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

j / k navigate · click thread line to collapse

0 pointsTeMPOraL3y ago0 comments

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.)

0 comments

chrismorgan3y ago

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.

TeMPOraLOP3y ago

That too.

chrismorgan3y ago

avgcorrection3y ago

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

j / k navigate · click thread line to collapse