On Sun, Sep 28, 2014 at 9:32 PM, Junio C Hamano <gits...@pobox.com> wrote: > Christian Couder <chrisc...@tuxfamily.org> writes: > >> From: Junio C Hamano <gits...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
