Hi, On Sun, 15 Jan 2012, Akim Demaille wrote:
> Le 13 janv. 2012 à 12:00, Jim Meyering a écrit : > > What do you think about generating ChangeLog from git log like > > we do for coreutils, grep, gzip, diffutils, etc.? > > I am personally very much in favor of it. But I'd like to be > sure that Joel is too (hi Joel, happy new year!). Thanks for asking, Akim. Now that gitlog-to-changelog has --amend, I'm much more interested in using it. However, I still dislike that gitlog-to-changelog sometimes merges adjacent log entries that have the same date and author lines. Aesthetically, I find this practice inconsistent. Practically, I find it unhelpful (what is the value of this complication?) and potentially confusing (in the case that someone has a source tarball and notices a ChangeLog entry for which he'd like to find the corresponding commit in git). Jim, I recall there was some recent discussion about all this on other mailing lists, and I've probably just recapped that here. What was the conclusion? Also, how is gitlog-to-changelog intended to behave at merge commits? For example, does it follow all parent commits or just the first? Does it print the merge commit itself? Sorry, I haven't taken the time to try it out. I'm just thinking of an old discussion about how bison.git might one day adopt the strategy of merging lower-numbered release series branches up to higher-numbered ones. Currently, we just cherry-pick both ways, keeping the logging issues simpler. That brings up another question. I cherry-pick with -x, which adds helpful info to the git log that's not interesting in the ChangeLog. Is there any automated way for gitlog-to-changelog to drop that info? (For example, --amend could support perl code that applies to all entries.) Happy new year.
