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
