bug-gnulib
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]