Joel E. Denny wrote: > 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.
I made it work that way because that is precisely how Emacs's changelog mode works. However, I found that behavior misleading in the presence of multi-paragraph ChangeLog entries. In that case, the normal same-say-same-committer commit-delimiter (a blank line) is also part of a commit log. Oops. Thus, the default is now *not* to merge any commit log entry with two or more paragraphs. > 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). I don't follow the above. How does grouping commits done by the same person and on the same day in one date-delimited block in a ChangeLog hinder archaeology? AFAICS, no information is lost. > 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? I didn't see the need for a new option (so didn't write it) and no one volunteered a patch. > Also, how is gitlog-to-changelog intended to behave at merge commits? I haven't thought about it, or even tried it, yet. > 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.) I'm really not that concerned with what the final ChangeLog looks like. Any serious archaeology will involve using git directly.
