4 ms·

Actually I think it is the other way around - since very few people would ever read commit histories - maybe if something really bad happened and we need to tra

by seer 2mo ago

Actually I think it is the other way around - since very few people would ever read commit histories - maybe if something really bad happened and we need to trace the audit trail ~once a month or something per team. But LLMs can traverse that tree at will in seconds and mine valuable info. Commits description value in my experience has shot up dramatically _with_ heavy LLM usage - they are forgetful and commit messages are just the right place to keep “context that might be needed, but not worth adding to the documentation corpus” - they are the “how did we get here” to the “current state” of docs files and code comments.

jurgenburgen 2mo ago
> Actually I think it is the other way around - since very few people would ever read commit histories - maybe if something really bad happened and we need to trace the audit trail ~once a month or something per team. It’s worse than that IMO. In over 10 years I’ve yet to have seen a team that even knows how to rebase, asking them to investigate commit logs or bisecting would be like teaching a cat to bark. Insisting on “good commits” (or even worse, conventional commits which is a poor solution to the wrong problem) is just adding bureaucracy where it’s least needed.
- seer 2mo ago
  Surprisingly enough I’ve encountered both kinds - people who don’t care a lot and despise any “mandatory commit rules”, and people who care _too much_ spending company time making their commits “perfect” which then nobody reads. I think it’s like with code formatters - now we have a tool that does the tedious thing on its own and unlocks human creativity where it is warranted… at least in the ideal case.
bquaresma 2mo ago
This is a great point that I hadn't considered, and it's definitely valuable. I've used APM systems that track errors by version, Sentry being one of them, and I've found it very useful when those errors include context about which commit introduced the issue. It makes it much easier for both me and the LLM I'm using to identify and understand the root cause.

by seer 2mo ago

jurgenburgen 2mo ago

> Actually I think it is the other way around - since very few people would ever read commit histories - maybe if something really bad happened and we need to trace the audit trail ~once a month or something per team. It’s worse than that IMO. In over 10 years I’ve yet to have seen a team that even knows how to rebase, asking them to investigate commit logs or bisecting would be like teaching a cat to bark. Insisting on “good commits” (or even worse, conventional commits which is a poor solution to the wrong problem) is just adding bureaucracy where it’s least needed.

seer 2mo ago
Surprisingly enough I’ve encountered both kinds - people who don’t care a lot and despise any “mandatory commit rules”, and people who care _too much_ spending company time making their commits “perfect” which then nobody reads. I think it’s like with code formatters - now we have a tool that does the tedious thing on its own and unlocks human creativity where it is warranted… at least in the ideal case.

bquaresma 2mo ago

This is a great point that I hadn't considered, and it's definitely valuable. I've used APM systems that track errors by version, Sentry being one of them, and I've found it very useful when those errors include context about which commit introduced the issue. It makes it much easier for both me and the LLM I'm using to identify and understand the root cause.