[t8sr]

I've worked with 5 different SCMs and I'm convinced that the reason why git repos often have such poor commit messages is because of the git commit style guide. So much of it only makes sense once you realize it's been optimized for like 5 of its original users reading it on 72 character terminal screens.

Asking people to fit a meaningful description of the change into 50 characters is silly, and it's IMO the reason why so many of them just write "fix bug" and call it a day.

Someone else has posted the Google guide for CL (change list) messages, but let me boost the signal: https://google.github.io/eng-practices/review/developer/cl-d...

This is, I believe, still the best guide out there. When I'm coaching juniors, I recommend this guide, over the opinionated and outdated git "best practices" and I think the results are much better.

[matt_kantor]

That Google guide also says that the first line of the commit message should be a "short summary of what is being done". Is your complaint that 50/72 characters is too short? How long can it be before no longer meets the Google criteria, in your opinion?

[t8sr]

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.

[Xss3]

Short is a relative term, and in this sense is relative to the long form explanation of the code.

If a commit is sufficiently complex the long form could be 600 characters and the short form 200.

[tabbott]

I think most projects limit commit message titles to 68-72 characters, not 50, which is indeed too little to say much of anything. I don't find it hard to write 70-character summaries, and as a maintainer, I find it very useful to have those available for skimming.

When I do maintainer work that involves skimming a list of dozens of commits for information, it's very helpful to have concise commit titles.

[everybodyknows]

The Google guide assumes a repo other than git. Consider this:

  Using tags

  Tags are manually entered labels that can be used to categorize CLs. These may be supported by tools or just used by team convention.

A "tag" means something entirely different to git.

[joedevon]

This is excellent, thank you! Don't hate me but I'm going to change my Claude Code /commit command by pointing it at this guide.