On Mon, 2009-07-06 at 17:22 +0200, Jim Meyering wrote:
Mark McLoughlin wrote:
> On Mon, 2009-07-06 at 16:19 +0200, Daniel Veillard wrote:
>> yeah, I think moving ChangeLog to ChangeLog.CVS and generating the
>> logs starting from today at "make dist" time is probably the best, it
>> will avoid copying over redundant informations.
>
> Cool.
>
>> On the other hand we
>> should try to keep the git log output coherent with the previous
>> format.
>
> FWIW, I think it's best to switch to a new format that better suits git.
>
> e.g. "git log --pretty=oneline" can be very useful, but only where
> people properly summarise the commit on the first line. If we used the
> typical ChangeLog format, it would be useless. Also, we don't need the
> date and author information twice.
>
> II think git commit messages generally more genuinely useful information
> than a ChangeLog entry - it seems to encourage people to more fully
> explain what they're doing.
>
> If we switch formats, 'git log --stat' is fine for Changelog - you get
> author, date, files changed etc.
Hi Mark,
What do you think of coreutils' logs?
It's generated and still ChangeLog-conforming, yet with an added
one-line summary and sometimes (for larger changes) more prose:
http://meyering.net/code/tmp/coreutils-ChangeLog
Looking at the git commits e.g.
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=24c727d3
it doesn't duplicate date/author and has a good first line summary, so
it's pretty good.
The one question I'd have is whether listing of per-file changes has any
value. IMHO, it tends to restrict the explanation people give about
about their commits. Looking at projects that don't do this, I think you
tend to get much more background on why the change is being made, not
just what changed.
Cheers,
Mark.