Re: [PATCH RFC] git-am: support any number of signatures
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 23, 2014, 17:15 UTC
- Message-ID
- <xmqqbnq6jm0s.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <CAP8UFD2W1r9859FgpBXqvdNLAfXoCwjpEFpTKXU6fGuC_8uvBg@mail.gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
Show 30 quoted lines
> On Mon, Sep 22, 2014 at 4:01 PM, Michael S. Tsirkin <mst@redhat.com> wrote: >> ... >> As a reminder, this old patchset (that I replied to) enhanced git am -s >> with an option to add different signatures depending on >> the option passed to the -s flag. >> E.g. I have >> [am "a"] >> signoff = "Acked-by: Michael S. Tsirkin <mst@redhat.com>" >> >> [am "r"] >> signoff = "Reviewed-by: Michael S. Tsirkin <mst@redhat.com>" >> >> [am "t"] >> signoff = "Tested-by: Michael S. Tsirkin <mst@redhat.com>" >> >> and now: >> git am -s art >> adds all 3 signatures when applying the patch. > > 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.
Show 7 quoted lines
> 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? 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?
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.