[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Feature request] gitlog-to-changelog: don't cluster multiple Change
From: |
Jim Meyering |
Subject: |
Re: [Feature request] gitlog-to-changelog: don't cluster multiple ChangeLog entries under the same "date line" |
Date: |
Fri, 23 Dec 2011 16:11:57 +0100 |
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 <address@hidden>
>>>
>>> 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 <address@hidden>
>>>
>>> correct previous ChangeLog entry: s/set -x/set -e/
>>> Spotted by Stefano Lattarini.
>>>
>>> 2011-12-22 Jim Meyering <address@hidden>
>>>
>>> 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.