Yeah, I specifically think 50 is too short. I am a big fan of brevity, but I think the sweet spot is somewhere around 100. Consider that all of these messages exceed the 50-character limit:
[startup] Don't drop uid until all controller fds are open
[bpf] Fix the exec exchange hitting verifier limit on Fedora
[controller] Optimize partial policy updates with delta
They're as short (IMO) as can be without omitting useful information, but git says they're all illegal by some margin.
I agree on the value of concise writing and dislike word salads, but if you're a junior engineer, then I have maybe 1 hour with you per week and I probably shouldn't spend that time being your English teacher.
I know I've seen some people recommend 50 (my guess is that's to make some room for metadata from commands like `git log --online` in an 80-column terminal?) but I've personally always capped all lines at 72, including the first. 100 seems like a reasonable limit too, but I probably wouldn't go above that.
> git says they're all illegal by some margin
Git will accept almost anything as a commit message. Is there a specific style guide you're referring to?
---
EDIT: Huh, I guess git does have an official recommendation. I'd never noticed this text in `git help commit`:
> Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description.
I wouldn't feel bad about not following this advice. Even the author doesn't seem dogmatic about it.
> if you're a junior engineer, then I have maybe 1 hour with you per week and I probably shouldn't spend that time being your English teacher
It's not important enough to make a big deal out of, but if I see it over and over from the same person I might mention it during code review ("your commit messages are a bit wordy; for example instead of '…', consider '…'") or write down as part of a style guide (e.g. if we're tagging commits like in your examples, wherever we wrote down the rules for that). It's the same for other unimportant things that it's nice to agree on (e.g. capitalization of initialisms in code—is it `.toJson()` or `.toJSON()`?).
I agree on the value of concise writing and dislike word salads, but if you're a junior engineer, then I have maybe 1 hour with you per week and I probably shouldn't spend that time being your English teacher.