Re: [PATCH RFC] git-am: support any number of signatures
- From
Christian Couder <christian.couder@gmail.com>
- Date
- Oct 12, 2014, 09:36 UTC
- 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:
Show 12 quoted lines
> 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.)
Show 15 quoted lines
>>> 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.