Re: Commit messages.




> 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.)

Right, so you wind up with a 25-line log message documenting a
one-line change.   And at most one of those 25 lines actually talks
about the specific file you're dealing with.   This is not helpful.
cvs annotate doesn't make it any better.   A log message should answer
the question "what does this particular delta do," not "what fifteen
changes that were made in the last ten days got committed at the same
time as this delta."

> 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.

ChangeLogs aren't tied to file revisions.   It's immensely helpful to
have good commit messages.   You can say "tough shit" if you want to,
and I can't do anything about it, but please don't claim that what
you're doing is helpful - it's not.   The ChangeLogs don't seem to be
all that helpful either.

> 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. 

That's great, but you don't have to do ``cd gtk+/gtk; cvs commit -m
"change everything"''.   Instead, you can identify individual files
that have changed, *look* at the changes, and do individual commits
documenting those changes.   It consumes slightly more time, but it
makes the commit logs readable.   This really is important.

> 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.

That's a bummer.   I think it would actually be more helpful if you
didn't use any commit message at all, rather than dumping the entire
ChangeLog for a mass commit into every file.

Oh well, c'est la vie.

			       _MelloN_



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]