Stefano Lattarini wrote: > On 12/23/2011 03:38 PM, Jim Meyering wrote: >> Stefano Lattarini wrote: >>> Hello Gnulibers. >>> >>> Currently, the `gitlog-to-changelog' script clusters ChangeLog entries with >>> the same date together, placing them under a single "date line" in the >>> generated output. >>> >>> So we have something like this: >>> >>> >>> $ ./build-aux/gitlog-to-changelog -- -n 2 76d222b >>> >>> 2011-12-22 Jim Meyering <meyer...@redhat.com> >>> >>> correct previous ChangeLog entry: s/set -x/set -e/ >>> Spotted by Stefano Lattarini. >>> >>> init.sh: avoid unwarranted test failure when using "set -x" >>> * tests/init.sh (compare): Ignore nonzero exit from >>> compare_dev_null_. >>> Otherwise, in a test script that uses "set -x" (like many in >>> vc-dwim) >>> a use like "compare exp out" would get evoke an unconditional >>> failure. >>> >>> >>> where I'd like to see something like this instead: >>> >>> $ ./build-aux/gitlog-to-changelog -- -n 2 76d222b >>> >>> 2011-12-22 Jim Meyering <meyer...@redhat.com> >>> >>> correct previous ChangeLog entry: s/set -x/set -e/ >>> Spotted by Stefano Lattarini. >>> >>> 2011-12-22 Jim Meyering <meyer...@redhat.com> >>> >>> init.sh: avoid unwarranted test failure when using "set -x" >>> * tests/init.sh (compare): Ignore nonzero exit from >>> compare_dev_null_. >>> Otherwise, in a test script that uses "set -x" (like many in >>> vc-dwim) >>> a use like "compare exp out" would get evoke an unconditional >>> failure. >>> >>> This latter format would match the current practice used in the Automake >>> hand-maintained ChangeLog. >>> >>> Would you consider adding an option to gitlog-to-changelog to support such a >>> format? >> >> Why? Solely for consistency, after you've made the switch from >> a manually-maintained to an automatically-generated ChangeLog file? >> > No, rather because, if you write git commit messages with multiple paragraphs > in the commit body (as I often do, and intend to continue to), the latter > format becomes essential. > >> Do you consider the duplication of the identical-date-name lines useful? >> > Yes; see above. > >> The default format emitted by gitlog-to-changelog matches >> what emacs' changelog-mode does. That seems consistent with >> the "avoid duplication" philosophy and also tends to keep the >> ChangeLog file more compact. >> > > I hope the above argument will make you reconsider this position; > ...
Position? I had not taken a position. Any feature request should be accompanied by justification. The questions above were simply my attempt to elicit that justification. Your explanation makes sense. However, I would prefer an adaptive/hybrid solution: if a commit log is composed of two or more paragraphs, keep it in a separate block. Otherwise, merge entries that would otherwise have a date--name--email header identical to the preceding one.