[bjourne]

1000 times this. There is also a significant drawback to having to much rules about commit messages which is that it can lead to horrible passive aggressive behavior: "Dear XYZ, I have undone your commit abf9de because the commit description was improper. In future, please follow the guidelines found at http://ABC. It saves work for all of us. Thanks in advance."

Keep in mind that there are different degrees here. Commit messages should be informative, yes, but worrying about whether they start with a capital letter or are written in past or present tense is waste of energy.

[stinos]

waste of energy

I wouldn't be surprised if having to read several pieces of any kind of text, be it a commit message or code, which are not written in a consistent manner is more of a cognitive load than reading pieces which are. (And higher cognitive load probably leads to litereally more energy being used). So if those assumptions hold, and assuming you want tto waste the least amount of energy possible, the question becomes: what process costs more energy? Making sure the text is consistent and adhering to certain standards, or not doing that and waste more energy interpreting it and/or having to worry about that.

[ryanbrunner]

Generally speaking though, I rarely care about reading multiple commit messages at a time. Outside of a PR (where to be honest, I'm far more interested in the PR description than the individual commit messages provided they're not something horrible like "changes"), I generally only look at commits in the context of a blame, which means I really need to understand one commit in isolation.

Good commit messages are super important in this case, of course, but the capitalization, verb tenses, and where line breaks occur have little to no real benefit, particularly if they're focused on over actually having a good commit message.

[bjourne]

Well, then you can go and prove that. :) Because the lack of evidence in either direction (wrt cognitive load and commit messages) points us towards the null hypothesis. In my own experience, fixing bugs in C code long abandoned by the original authors, it doesn't matter one bit if the commit message reads like a novel or literally just "fsjdlkfdjlsfl fskjl". All that matters is the change is self-contained and references bug tracker ids and mailing list discussions.

Also in my experience, passive-aggressive power trippers love anal retentive rules. Hence adding more than necessary carries a significant risk.

[int_19h]

A simple rule of thumb to prevent this: if it made past code review, it stays, because, by definition, nobody cared enough to notice it and/or call it out.

(This goes only for style guide violations, of course, not behavioral changes.)