Re: Commit messages.

[Owen Taylor <otaylor redhat com>]

Ted Lemon <mellon@hoffman.vix.com> writes:

> I'm just now going through the commit messages on gtkbox.c to see if a
> problem I'm having is the result of a change, or if it's always been
> that way.   The commit messages for this are completely useless - it
> looks like I'm going to just have to diff all the versions to see if
> there's a relevant change.

cvs annotate is very useful for such things.
 
> The commit messages seem to be ChangeLog entries for large commits,
> rather than messages that document the specific change being committed
> to a specific file.   That is, if you make the following change to
> gtkbox.c:
> 
> -	int i = 0;
> +	int i = 1;
> 
> The commit message will mention a bunch of changes to gtkwidget.c and
> gtkwidget.h, but may not mention any change at all to gtkbox.c,
> because (I presume) that change was considered to be too unimportant
> to mention.

No, every change will be mentioned in the ChangeLog, and hence
in that large commit message. (When identical changes are done
to many files, they may be mentioned in aggregate, but will be
mentioned.)

> When I do commits on projects where I have commit access (I don't have
> gtk commit access), I commit my changes one file at a time, and
> mention each significant change to the file, as well as what it's
> related to (if appropriate).   Keeping a ChangeLog is great, but
> ChangeLog messages and cvs commit messages are two different things,
> and shouldn't be confused.
> 
> Being a user with no power to set policy, this is obviously just my
> random flame about this practice and can be taken with a grain of
> salt, but I really hope people will pay attention to this - the
> current commit message practice produces *huge* commit logs with an
> extremely poor signal to noise ratio.

For GTK+, the ChangeLog is considered primary, and the commit
messages secondary. We spend quite a bit of effort to make
sure we have good ChangeLogs, if we get less then perfect
commit messages, then, well, that's the breaks.

Also, we take a lot of concern to make sure that our commits are
sensible, which usually means thinking about and discussing changes
before commiting them, which sometimes means large commits. 

So, yes, it would be ideal to separate out each independent change
into a separate commit, but basically, it won't change any time soon.

Sorry,
                                        Owen