git - the first line in a commit message is the subject line

[David Zeuthen]

On Sat, 2006-07-29 at 17:25 +0200, Kay Sievers wrote:
> On Sat, 2006-07-29 at 10:37 -0400, David Zeuthen wrote:
> > Please wrap commit messages at 70-80 characters per line, thanks.
> > Otherwise 'git log' is not funny to look at from the command line.
> 
> > > diff-tree 013d2b5ea3e51b5f8f100656c5a4ee78e32030b0 (from ded2e6c3119447b34e7cd492c7a126a18d0f979a)
> > > Author: Richard <richard at hughsie.com>
> > > Date:   Fri Jul 28 22:35:20 2006 +0100
> > > 
> > >     Correct the error name, obviously a copy/paste error that's lived undetected in CVS for years.
> 
> Right, we all should please _always_ add a _short_ and nice description
> of the commit to the _first_ line of the commit and terminate by two
> newlines (it will work without the second newline, but that is not nice
> for the interfaces).

Right. Thanks for pointing this out.

> Don't put too many filler words in there. This first line is the only
> text that makes it into the autogenerated changelog and the gitweb
> browser list. People need to understand that line without too much
> parsing. In this case it could just be something like:
>   correct D-BUS error name 'Remove'
> 
> And right, lines should be wrapped _before_ commiting, cause the
> commandline interface does not do this for you.

So the question is what comes after the initial short description. We
used to have this style

 * foo.c:
   (frobnicate): tweak baz
   (bazificate): poke bar after blah

which I never really found too useful. 

I think just moving to a format where the author/committer writes a
concise explanation of the diff without specifying what functions he
touches is sufficient. All the other projects including linux, udev,
cairo, X.org do that. IIRC it also have the benefit that you can use
tools that take the mail with the patch in it when you apply it. We
should do that, yes?

    David