From: Christian Couder <christian.couder@gmail.com>
Date: Sun, 12 Oct 2014 09:36:52 GMT
Subject: Re: [PATCH RFC] git-am: support any number of signatures
Message-ID: <CAP8UFD1ATE-CtqXJyd7qDw-34RJ3ZQibHo6BSi+42hkaPNzz5w@mail.gmail.com>
In-Reply-To: <7viok7k0c0.fsf@alter.siamese.dyndns.org>

On Sun, Sep 28, 2014 at 9:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
>
>> From: Junio C Hamano <gitster@pobox.com>
>>
>>> If that is what happens, it is not a workable workaround to set Sob to
>>> addIfDifferent only for this invocation.
>>
>> Setting S-o-b to addIfDifferent for this invocation would not add the
>> S-o-b at the end, because another S-o-b still exists in the input
>> message "seen" when the last S-o-b is processed.
>
> So there is no workaround whatsoever, which is worse X-<.

I think there might be a misunderstanding.

With v16 you can easily choose if you want to have the S-o-b in the
output or not, when there is already one, see:

$ cat test.txt

Signed-off-by: <Michael>

$ cat test.txt | git interpret-trailers --trailer 'Acked-by:
<Michael>' --trailer 'Reviewed-by: <Michael>' --trailer 'Tested-by:
<Michael>' --trailer 'Signed-off-by: <Michael>'

Signed-off-by: <Michael>
Acked-by: <Michael>
Reviewed-by: <Michael>
Tested-by: <Michael>
Signed-off-by: <Michael>

$ cat test.txt | git -c 'trailer.ifexists=addIfDifferent'
interpret-trailers --trailer 'Acked-by: <Michael>' --trailer
'Reviewed-by: <Michael>' --trailer 'Tested-by: <Michael>' --trailer
'Signed-off-by: <Michael>'

Signed-off-by: <Michael>
Acked-by: <Michael>
Reviewed-by: <Michael>
Tested-by: <Michael>

Or:

$ cat test.txt | git -c
'trailer.Signed-off-by.ifexists=addIfDifferent' interpret-trailers
--trailer 'Acked-by: <Michael>' --trailer 'Reviewed-by: <Michael>'
--trailer 'Tested-by: <Michael>' --trailer 'Signed-off-by: <Michael>'

Signed-off-by: <Michael>
Acked-by: <Michael>
Reviewed-by: <Michael>
Tested-by: <Michael>

(There was a small bug in v15 with the last command above.)

>>> Alternatively, if Neighbor-ness is evaluated first before you add A/R/T
>>> in response to this request, then you'd refrain from adding a duplicate
>>> Sob. It wasn't quite clear from your description what your design was,
>>> and your explanation above is not still clear, at least to me.
>>
>> I hope it is clearer now. Maybe I should add something in the doc to
>> better explain how it works.
>
> I doubt that it would help the users materially to document that we
> chose to implement a less useful way when there are multiple ways in
> which a feature can work, though.
>
> Unless I am mis-reading you and you are actually saying that the
> users can emulate the "atomic" variant without much hassle by doing
> X and Y, that is.  If so, it would help readers to document them.

If you would like me to document the 3 above commands in an example, I
am ok to do that.

Thanks,
Christian.