I don't understand how you could possibly tolerate messy commit messages. It's as if you've never had to do a code investigation/audit ever, heaven forbid you do.
> I don't understand how you could possibly tolerate messy commit messages.
I mean, it's pretty easy. You just like, tolerate it.
I'm sure there are contexts where strict rules are important, but in my experience most of the time fussy commit message rules are put in place it's because someone has reimagined themselves as the gordon ramsey of code and the people rolling their eyes don't want to get entrenched in a political battle where they're against "professionalism", so they just deal with it, or someone with mild OCD is inflicting it on everyone else. (I know I'm being harsh and I'm writing this tongue in cheek, I don't really think that badly of people that are super fussy about these things, but I've rarely seen any actual utility come from strict commit rules).
I don't think that's a fair statement, at least based on my own experience. When I'm investigating how code arrived at a certain state, I'm looking primarily at the code.
The commit messages are nice as indicators of intent, but I don't rely on them. The real change is in the code, not what somebody remembered to write in a summary of the change.
Well, I don't tolerate just anything. But I much rather have "fixed fs race" than "merged a13b1z: <issue 14365><subsystem core><signoff:dave> changed fs_handle.lock to use blargh_lock_45"
