3 ms·
This seems like some sort of polarizing issue for some, but the reasons "why not" are totally unclear to me. I'm a regular advocate for detailed and self-explan
by Willish42 2y ago
This seems like some sort of polarizing issue for some, but the reasons "why not" are totally unclear to me. I'm a regular advocate for detailed and self-explanatory code change "commit" descriptions, and I feel as if I'm in the minority trying to advocate for (at a minimum) proper bug tagging and context links in description for PRs that I come across.
This gets omitted sufficiently often that I have largely given up on requiring it except for noteworthy code changes that I am a reviewer for. It's a very hard thing to get consistent adherence to in my experience. I highly recommend others in a similar boat to at least lead by example and annotate your code changes consistently so you can at least identify relevant changes that you wrote. Getting everybody else to is another story...
- _dark_matter_ 2y agoFor me, it's a time, and more important attention, tradeoff. I have never once needed to bisect commits to figure out why/who made a change. A blame can lead to a PR, which is usually auto linked to a ticket or has some relevant convos. Commit messages feel like a relic of the past (to me, and my teams workflow). Ymmv!
- citrin_ru 2y agoPR/ticket are additional levels of indirection. It’s more convenient when you can run git show for revision from blame and get all necessary information. Also people (teams) who write bad commit messages often write bad ticket descriptions/comments too.