Re: Why have a ChangeLog file if you already have commit messages?


On 9/15/07, Jaap Haitsma <jaap haitsma org> wrote:
> Talking to Daniel "Cheese" Siegel we asked ourselves:
> Why do all GNOME projects have a ChangeLog file?
> Isn't it redundant when you just save a commit message.

When I've seen projects just dump CVS or SVN log to ChangeLog,
typically the resulting ChangeLog sucked badly; most commit messages
are not very good, while ChangeLog entries frequently are. Why the
difference? Who knows. It is a real difference whether there's a
logical reason for it or not though.

(For me I think the difference is that I do the ChangeLog in Emacs
with 'C-x 4 a' and I do the commit message with VISUAL=vi, so for
projects where we don't bother with ChangeLog my commit messages are
junky. I don't know why it happens for other people.)

People say git helps with this, though I admit I don't see how (for me
at least) the bad commit messages vs. nice ChangeLog entries are
related to the SCM system, since my best guess at why my no-ChangeLog
commit messages are junk is the difference in editor.

The log for Cairo looks pretty good for example so clearly the
"autogenerate" approach works for someone:;a=log

Perhaps it just comes down to the maintainer being a hardass about
commit message quality in the same way they might be about ChangeLog
entries. I think Carl summarized it that way at GUADEC.

I don't agree that the purpose of ChangeLog (with svn at least) is
offline access, though. The reason I use it in my projects is that
when people don't use it, specifically when I don't, the quality of
the log suffers. (For my projects I always just cut-and-paste from
ChangeLog to the commit message.)

I guess the summary is, the focus should be on whether people write
good change history messages, and maintainers should probably feel
free to use any mechanism that works for them for that. But as soon as
messages start to be useless, like "fixed stuff," "hacked on foo.c,"
it's a problem no matter what technology is used to save the messages.


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