From: Junio C Hamano <gitster@pobox.com>
To: Christian Couder <christian.couder@gmail.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
Git Mailing List <git@vger.kernel.org>,
Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [PATCH RFC] git-am: support any number of signatures
Date: Wed, 24 Sep 2014 22:04:08 -0700 [thread overview]
Message-ID: <xmqq1tr0cmuv.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <xmqqbnq6jm0s.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Tue, 23 Sep 2014 10:15:47 -0700")
Junio C Hamano <gitster@pobox.com> 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.
next prev parent reply other threads:[~2014-09-25 5:04 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-12 16:12 [PATCH RFC] git-am: support any number of signatures Michael S. Tsirkin
2014-06-12 19:07 ` Junio C Hamano
2014-06-13 8:00 ` Michael S. Tsirkin
2014-06-13 17:32 ` Junio C Hamano
2014-06-15 10:27 ` Michael S. Tsirkin
2014-06-16 18:06 ` Junio C Hamano
2014-06-18 3:09 ` Michael S. Tsirkin
2014-06-18 6:49 ` Junio C Hamano
2014-06-18 7:33 ` Michael S. Tsirkin
2014-06-18 17:51 ` Junio C Hamano
2014-06-18 18:23 ` Michael S. Tsirkin
2014-09-22 14:01 ` Michael S. Tsirkin
2014-09-22 17:58 ` Junio C Hamano
2014-09-23 7:45 ` Christian Couder
2014-09-23 8:07 ` Michael S. Tsirkin
2014-09-24 10:00 ` Christian Couder
2014-10-07 21:33 ` Michael S. Tsirkin
2014-09-23 17:15 ` Junio C Hamano
2014-09-25 5:04 ` Junio C Hamano [this message]
2014-09-25 10:04 ` Christian Couder
2014-09-25 16:20 ` Junio C Hamano
2014-09-28 11:36 ` Christian Couder
[not found] ` <7viok7k0c0.fsf@alter.siamese.dyndns.org>
2014-10-12 9:36 ` Christian Couder
2014-10-13 5:09 ` Christian Couder
2014-10-13 22:05 ` Junio C Hamano
2014-10-14 5:29 ` Christian Couder
2014-10-07 21:29 ` Michael S. Tsirkin
2014-10-07 21:39 ` Jeff King
2014-10-07 21:41 ` Junio C Hamano
2014-06-12 19:25 ` René Scharfe
2014-06-13 8:01 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq1tr0cmuv.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=chriscool@tuxfamily.org \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=mst@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.