3 ms·

I hate that rule about 50 characters. IIRC, it started because someone noticed that the average commit message in the linux kernel is about 50 characters. Then,

by ufo 5y ago

I hate that rule about 50 characters. IIRC, it started because someone noticed that the average commit message in the linux kernel is about 50 characters. Then, for whatever reason it morphed into this widely propagated mantra saying that the maximum should be 50 characters.

slaymaker1907 5y ago
Writing a good commit message within those constraints is kind of like writing a haiku. It's kind of entertaining sometimes, though I think it should be a suggestion rather than a rule.
- remram 5y ago
  It's usually fine unless your change concerns a specific function/module whose name is 20+ characters. Often I am renaming a function/module/package and can't fit its name in the first line which I find really annoying. Trying to refer to it in a different way or abbreviating it is so awkward.
js2 5y ago
I know the articles calls it a rule, but really it's more a guideline. It's so that `git log --oneline` and `git shortlog` produce succinct output. It's also the email subject when using `git format-patch`. With all of these, the idea is to have a quick-to-read summary of the commit. That's all, really.
kibwen 5y ago
Indeed, I follow these rules but I routinely violate the 50 character limit. It's far more important for subject lines to be useful than to be maximally succinct; I'm not out here trying to write an essay in the subject line, but I do need it to be appropriately descriptive.
mhitza 5y ago
I think Linus himself recommended at some point that 50 character subject restriction (in a time when 80 character wide code lines were also still a recommendation). That wouldn't be important in itself, but Github trims your message at 50 characters as well. Because of that "feature" alone it's annoying to pass that limit.
- derkades 5y ago
  GitHub trims at 72, only warns at 50
clktmr 5y ago
It's often difficult to find a summary in 50 characters, and it should be! Anything that's longer than 50 characters is probably too verbose too be viewed as a log.
salamander014 4y ago
I try to subscribe to the idea that if you cannot adequately describe your commit in a small number of characters (~50 is plenty I feel), your commit is likely too complicated. One size does not fit all, and if a workflow ain't broken there's usually no need to fix it. However most workflows are imperfect, there is almost always room for improvement. But in the general case I find that if commits are not themselves concise and simple changes, they often should be broken up so that the moving pieces can be better tracked when looking back at the history.

by ufo 5y ago

slaymaker1907 5y ago

Writing a good commit message within those constraints is kind of like writing a haiku. It's kind of entertaining sometimes, though I think it should be a suggestion rather than a rule.

remram 5y ago
It's usually fine unless your change concerns a specific function/module whose name is 20+ characters. Often I am renaming a function/module/package and can't fit its name in the first line which I find really annoying. Trying to refer to it in a different way or abbreviating it is so awkward.

js2 5y ago

I know the articles calls it a rule, but really it's more a guideline. It's so that `git log --oneline` and `git shortlog` produce succinct output. It's also the email subject when using `git format-patch`. With all of these, the idea is to have a quick-to-read summary of the commit. That's all, really.

kibwen 5y ago

Indeed, I follow these rules but I routinely violate the 50 character limit. It's far more important for subject lines to be useful than to be maximally succinct; I'm not out here trying to write an essay in the subject line, but I do need it to be appropriately descriptive.

mhitza 5y ago

I think Linus himself recommended at some point that 50 character subject restriction (in a time when 80 character wide code lines were also still a recommendation). That wouldn't be important in itself, but Github trims your message at 50 characters as well. Because of that "feature" alone it's annoying to pass that limit.

derkades 5y ago
GitHub trims at 72, only warns at 50

clktmr 5y ago

It's often difficult to find a summary in 50 characters, and it should be! Anything that's longer than 50 characters is probably too verbose too be viewed as a log.

salamander014 4y ago

I try to subscribe to the idea that if you cannot adequately describe your commit in a small number of characters (~50 is plenty I feel), your commit is likely too complicated. One size does not fit all, and if a workflow ain't broken there's usually no need to fix it. However most workflows are imperfect, there is almost always room for improvement. But in the general case I find that if commits are not themselves concise and simple changes, they often should be broken up so that the moving pieces can be better tracked when looking back at the history.