(no title)
t8sr | 3 months ago
[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.
matt_kantor|3 months ago
> 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.
matt_kantor|3 months ago
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()`?).