Re: On autogenerated ChangeLog

[Dan Winship <danw gnome org>]

Alexander Larsson wrote:
> On Mon, 2009-04-20 at 10:00 -0400, Dan Winship wrote:
>> Here's something to generate a fairly traditional-looking ChangeLog
>> (though working on the assumption that you're doing the subject vs body
>> split in your git commit messages):
>>
>> git log --date=short --pretty=format:"@@@@%cd  %an  <%ae>%n%n%s%n%n%b" |
>> perl -ne 'if (/^\s*$/) { if (!$blank) { print; $blank=1; } } else
>> {$blank=0; if (!s/^@@@@// && !/^\t/) { print "\t"; } print; }'
>>
>> %cd is commit date, %an is Author name and %ae is Author email. The perl
>> part indents every commit description line that doesn't already start
>> with a tab, and removes duplicate blank lines. Assuming the lines were
>> wrapped to 72 columns to start with, this will make them look too long,
>> but won't actually cause anything new to wrap.
> 
> You can rewrap with fmt --split-only.

Yeah, but that ends up looking bad if the lines were already wrapped
reasonably. (Also, that's a GNU-only option, so we'd probably want to
just reimplement it in the perl script if we did want.)

> That looks good though, but would be nice to have some reference to what
> files changed. Makes it easy to search for that.

You can do that in a slightly lame way by adding "--name-only" to the
git log command line. Doing something clearer than that would only take
a little more work.

But I've been including filenames or function names in most of my commit
messages, so I feel like adding them explicitly to the ChangeLog as well
would end up being redundant...

So, actually, what exactly IS the use case of ChangeLog if there is git
history on one end and NEWS on the other? Who are the people who need
more information than NEWS gives, but who would not want to actually
check out the source tree, and what information, exactly, do they need?

-- Dan