and the useful info that comes after it can of course be included in the commit. but starting at line 3!
well, well.
And more explicitly: https://github.com/torvalds/linux/pull/17#issuecomment-56599...
We have been moving towards commit messages similar to those used in the kernel development (i.e. longer, descriptive) and it has proven very useful indeed
Long commit messages are good. But a good first line is essential, since, as Linus points out, that is what gets shown by default by a lot of tools.
vim's syntax highlighting will warn you when you write too much, so i usually do not really notice the length (afair emacs does as well).
Github itself even uses these rules [2] so I think it's slightly annoying people don't follow them as it looks worse if you use long first lines on the website.
[1] http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa... [2] https://github.com/blog/926-shiny-new-commit-styles
Open up any git GUI; gitk or SourceTree are my two favorite. If you keep your summary lines under 50 characters you can quickly scan a maximal number of commits. Detailed descriptions are great and should be included as well for any substantial commits, but that is not what you want in the summary. That should be added in separate paragraphs after the summary line.
This is not arbitrary, and it has nothing to do with the ability to line wrap, it's about efficient communication faced with a history of tens or hundreds of thousands of commits over time.
The short message first, longer message after is a pretty good middle ground. But if that first sentence is useless, I'd rather just have a single commit message that accurately describes the commit.
I think this is the part people don't understand. The first line should be < 72 chars. After that (and a blank line), write as much as you want.