bison-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] Supporting git-merge-changelog


From: Eric Blake
Subject: Re: [PATCH] Supporting git-merge-changelog
Date: Tue, 26 Aug 2008 22:14:06 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Akim Demaille <akim <at> lrde.epita.fr> writes:

> 
> And for writing the git log entries, since I use the ChangeLog mode,
> they are the same.

This same debate already came up on the coreutils list.  Jim is currently not 
using a ChangeLog (just the git log); he then uses a script to convert git logs 
back to ChangeLog at release time.  He also helped develop vc-dwim, a package 
designed to make checking git log entries for consistency (and which is vc-
agnostic; it is supposed to work for more than just git).

Personally, I _like_ the ChangeLog alongside the git log.  Not only can you 
correct typos in the changelog with a subsequent commit, but you can also 
attribute multiple authors (Jim already conceded that for coreutils, that was a 
shortcoming of his git-to-changelog script - how do you make the reconstructed 
ChangeLog credit multiple authors with copyright interest when git log only 
allows one --author per commit?).  It is also possible to set up git hooks that 
will pre-populate your commit message with data culled from the current state 
of ChangeLog.  Therefore, even though Jim has abandoned ChangeLog for 
coreutils, I have so far kept it for M4.

My final argument in favor of keeping the ChangeLog is Bruno's git-merge-
changelog script.  It makes merging distinct git branches, each with actively 
maintained ChangeLog entries, much easier.  Conflicts, when they do happen, are 
floated to the top of the file for immediate review.  But generally, conflicts 
don't even occur (yes, the result is not always in chronological order, but 
neither would it be if you used git-to-changelog conversion).  And bison is 
already set up to use git-merge-changelog, provided that you install it per 
directions in HACKING.

But as I am not the primary maintainer, I could go either way.  Just be sure 
that if you do decide to switch to 'git log' as the primary log, that you 
follow Jim's precedence with coreutils; consistency between GNU projects is a 
nice goal.

-- 
Eric Blake






reply via email to

[Prev in Thread] Current Thread [Next in Thread]