CommitMessageConventions
From Git SCM Wiki
At the lowest level of git that defines the object format, a commit object consists of structural header in fixed format, followed by any binary blob you feed git-commit-tree from the standard input. I do not recall the details of the implementation offhand, but we _might_ chomp at the first NUL and if we did so I may say it is a bug -- commit-tree should not care what "the log message" part consists of.
It is however quite a different story when it comes to the higher level tools that come with git. The log summarization facilities to let humans interact with the commits expect that a commit log message consists of a one-line "summary", a blank line, and then the body of the message. These "log listers" are:
- git log --pretty=oneline
- gitk
- gitweb
- gitview
- git shortlog
The "one-line summary plus body of the message" has a strong correlation with how we communicate patches via e-mail. You do not start a sentence on the "Subject: " header and continue on to the body of the message, starting the body halfway of the sentence. Instead, you try to make sure you write something sensible by itself on the "Subject: " header to help the recipient when later scanning for it among bunch of messages, and you write a full paragraph that you can understand without reading the subject line first. The following commands that deal with e-mailed patches expect you to follow that convention:
- git am
- git applymbox
- git format-patch
Reference: http://article.gmane.org/gmane.comp.version-control.git/21987 email in the git mailing list
