Re: [PATCH RFC] git-am: support any number of signatures

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> What would be more interesting is if the primitives you have,
> e.g. "replace", "append", etc. are sufficient to express his use
> case and similar ones.  For example, when working on multiple
> trailers (e.g. "am --trailer art" would muck with three kinds), how
> should "do this if exists at the end and do that otherwise" work?
> To an existing message ends with Michael's Signed-off-by:, if his
> "git am --trailer arts" is called to add these three and then a
> Signed-off-by: from him, should it add an extra S-o-b (because his
> existing S-o-b will no longer be the last one after adding Acked and
> others), or should it refrain from doing so?  Can you express both
> preferences?

By the way, the answer to this can be "no, but it does not matter.",
of course.  If you can only express the latter (i.e. the addition of
multiple trailers is done as an atomic event, what was the last
before addition of them will be treated during the whole time of
addition of all of them), that may be perfectly fine because the
former (i.e. the addition is done one by one) can easily be emulated
by calling the program multiple times, feeding the trailers one by
one.

> Another thing that got me wondered this morning while I was thinking
> about this topic was if "replace" is flexible enough.  We may want
> to have "if an entry exists (not necessarily at the end), remove it
> and then append a new one with this value at the end" to implement
> "Last-tested-by: me@my.domain", for example.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]