hvr
commented
9 years ago Fwiw, the 50-char convention is not just a single guy's opinion anymore, it's found its way into various tooling; e.g.
- GitHub truncates >50 char commit-subjects
- gitweb (used on http://git.haskell.org/) truncates >50 char commit-subjects
- VIM (when used as commit-editor) error-highlights chars beyond the 50th column in commit-subjects
- Emacs' Git commit editor (via magit) does so as well
- When a Git commit is turned into an email, the subject line is typically extended by mailing-list specific markers and/or a commit-hash prefix; in that case 72 chars would be too much already
just to name a few OTTOMH; I'm sure I can find other such examples; So I find it quite reasonable to keep this a warning, to make ppl aware their commit messages will cause minor annoyances down the road.
thomie
I cannot find any good rational for the 50 character limit. It's seems to be just a suggestion by tpope ("you should shoot for about 50 characters (though this isn’t a hard maximum)"). So for the moment, I left it a suggestion in the 80 character hard limit message. But this is what the Linux kernel documentation has to say for example (and i agree wholeheartedly):
Bear in mind that the "summary phrase" of your email becomes a globally-unique identifier for that patch. It propagates all the way into the git changelog. The "summary phrase" may later be used in developer discussions which refer to the patch. People will want to google for the "summary phrase" to read discussion regarding that patch. It will also be the only thing that people may quickly see when, two or three months later, they are going through perhaps thousands of patches using tools such as "gitk" or "git log --oneline".
For these reasons, the "summary" must be no more than 70-75 characters, and it must describe both what the patch changes, as well as why the patch might be necessary. It is challenging to be both succinct and descriptive, but that is what a well-written summary should do.