[jeremyjh]

I find commit logs useful even if I'm the only person ever reading them. I like to be able to git blame on a line and be reminded of the context in which I did something and what I was trying to solve. I don't bother to pretty up my feature branches though, I just squash them so that master has a clear story

[SilverRed]

How we do it at work is every single commit message must have a ticket number in it. This is super easy to do and super useful. Even if the commit message is "fix exception #1823" you can go and look up #1823 and see what that issue was to make sure you don't reintroduce it with your change. You will always find more info and context in the ticket than in git commit messages.

[w0mbat]

I hate this. Often I am rewriting a bad comment, or improving the working code I checked in yesterday whose ticket has already been closed. Deleting an unneeded #include. All kinds of stuff for which there is no open ticket.

This kind of rule prevents people from maintaining the code base as they go. I have literally quit a company because of bullshit such as this. I was a senior engineer and could not fix a typo in a comment without a bug number and two code reviews.

[SilverRed]

This has been a non issue for me. I just slap minor fixes in with other tickets even if they are not related. Usually I just drop a comment in the review page with "saw this other issue and fixed it"

Short circuiting the review and QA steps is not ideal. A reviewer should see the change is just a comment typo fix and accept it even if it has nothing to do with the current ticket.

[w0mbat]

The log is a useful byproduct, but it's not the product.