Re: Experimental repositories on git.gnome.org

[Shaun McCance <shaunm gnome org>]

On Thu, 2009-01-15 at 15:08 -0500, Owen Taylor wrote:
> On Thu, 2009-01-15 at 11:53 -0800, Sandy Armstrong wrote:
> 
> > > Stripping the header line and leading whitespace is pretty clearly a
> > > good thing (though it can occasionally lose author information when it
> > > is different from the committer). Stripping the file names is a bit more
> > > controversial.
> > 
> > Maybe I'm missing something, but I'm not really sure I understand why 
> > file name references are being removed.  I guess you have a shorter 
> > message, but you have basically no context when you run `git log` to see 
> > what's been going on.  The example you give above is pretty meaningless 
> > to me, and I'm pretty sure it would be hard to follow a similar message 
> > in modules I maintain or contribute to.
> > 
> > Is this the common convention in projects using git?  If so, I really 
> > don't understand what commit message format has to do with choice of 
> > source control [1]...
> 
> There are really two separate points to the stripping process.
> 
>  1) What makes a good ChangeLog message is a bit verbose for a commit
>     message.... there's no point in listing the files 
> 
>  2) To provide a good Subject for the commit
> 
> Of these, the second is a lot more important.
> 
> git commit messages aren't just arbitrary - they have a structure as
> 
>  <single line subject>
>  
>  <multiline body>
> 
> This is partially just conventional, but a lot of tools makes use of the
> structure (e.g., the log in cgit just shows the Subject), so if the
> first line of the converted log messages are all:
> 
>  <date> <author>
> 
> that will look pretty confusing and weird. And it's not great even if
> the first lines are
> 
>  gtk/gtkwidget.c:
> 
> Or something like that. An approach that has some some then is to
> use something like the current stripping process to extract a guess
> at a subject, and then repeat the log message minimally munged as
> the body.

I mentioned this on IRC, but I'll repeat it here for posterity.
I think the munging of the full body should be as minimal as
possible.  By all means, we should try our best to extract as
meaningful of a subject line as possible.  But after that, I
think the full body should just be the whole commit message,
possibly with the date line removed as consistent indentation
stripped.  Reasons:

1) Mungers, by their very nature, have to rely on some degree
of consistency in what they're munging.  I'd be afraid that
somebody, at some point in time, made a commit message like
  * Fixed bug #555: blah blah blah
Then the munger would think "Fixed bug #555" is a file name.

2) With CVS and SVN, people made big commits with unrelated
changes.  Git can easily tell you which files go with the
entire commit message, but it can't tell you which files go
with which paragraph of the commit message.  That's valuable
information for some commits, and I'd hate to lose it.

I think we should just suck it up and deal with the fact that
the commit messages are old-school.  Just focus on extracting
and prepending good subject lines.

--
Shaun