From: Christian Couder <christian.couder@gmail.com>
To: Junio C Hamano <gitster@pobox.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: Thu, 25 Sep 2014 12:04:48 +0200 [thread overview]
Message-ID: <CAP8UFD0kfSBhSwu5Mb46XEHqYCE0SEsZd_3c0Sm4WzEc-NNc7w@mail.gmail.com> (raw)
In-Reply-To: <xmqqbnq6jm0s.fsf@gitster.dls.corp.google.com>
On Tue, Sep 23, 2014 at 7:15 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Christian Couder <christian.couder@gmail.com> writes:
>
>>
>> This is probably not as simple as you would like but it works with
>> something like:
>>
>> $ git interpret-trailers --trailer "Acked-by: Michael S. Tsirkin
>> <mst@redhat.com>" --trailer "Reviewed-by: Michael S. Tsirkin
>> <mst@redhat.com>" --trailer "Tested-by: Michael S. Tsirkin
>> <mst@redhat.com>" 0001-foo.patch >to_apply/0001-foo.patch
>>
>> and then:
>>
>> $ git am to_apply/*.patch
>
> If I understand it correctly, Michael is envisioning to implement
> his "git am -s art" (I would recommend against reusing -s for this,
> though. "git am --trailer art" is fine) and doing so by using
> interpret-trailers as an internal implementation detail, so I would
> say the above is a perfectly fine way to do so. An equivalent of
> that command line is synthesized and run internally in his version
> of "git am" when his "git am" sees "--trailer art" option using
> those am.{"a","r","t"}.trailer configuration variables.
Yeah, that's the idea, except that I think "--trailer art" should mean
a trailer like:
art: <default value>
(if there is no trailer.art.key config variable defined).
Having am.{"a","r","t"}.trailer configuration variables to define full
trailers seems too specific and quite confusing regarding how git
interpret-trailers work without those variables.
>> Also by using something like:
>>
>> $ git config trailer.a.key Acked-by
>> $ git config trailer.r.key Reviewed-by
>> $ git config trailer.t.key Tested-by
>>
>> the first command could be simplified to:
>
> So I think this mechanism buys Michael's use case very little, if
> any. It might be useful in other contexts, though.
>
> 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?
The way the "trailer.<foo>.ifexists" and "trailer.<foo>.where" work is
quite orthogonal to the way we decide what the content of the trailer
is.
If we make "--trailer art" mean "--trailer Acked-by: Michael --trailer
Reviewed-by: Michael --trailer Tested-by: Michael", then it should
work as if we had passed the latter to the command line.
> 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?
The default for "trailer.where" is "end", and for "trailer.ifexists"
it is "addIfDifferentNeighbor".
That means that by default it will add the four new trailers at the end.
If either "trailer.ifexists" or "trailer.S-o-b.ifexists" is set to
"addIfDifferent", then only the first 3 new trailers will be added at
the end. So yes you can express both preferences.
> 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.
That's what "replace" does already. That's why I changed the previous
name for this option from "overwrite" to "replace". You have an
"overwrite behavior" with where = after and ifexist = replace, and you
have a "remove old one and append new one behavior" with where = end
and ifexist = replace.
Thanks,
Christian.
next prev parent reply other threads:[~2014-09-25 10: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
2014-09-25 10:04 ` Christian Couder [this message]
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=CAP8UFD0kfSBhSwu5Mb46XEHqYCE0SEsZd_3c0Sm4WzEc-NNc7w@mail.gmail.com \
--to=christian.couder@gmail.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).