Re: [PATCH RFC] git-am: support any number of signatures
- From
- Michael S. Tsirkin <mst@redhat.com>
- Date
- Oct 7, 2014, 21:29 UTC
- Message-ID
- <20141007212937.GA14632@redhat.com>
- In-Reply-To
- <xmqqbnq6jm0s.fsf@gitster.dls.corp.google.com>
On Tue, Sep 23, 2014 at 10:15:47AM -0700, Junio C Hamano wrote:
Show 41 quoted lines
> Christian Couder <christian.couder@gmail.com> writes:
>
> > 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.Hmm I wonder why do you dislike reusing -s with a parameter for this. To me, this looks like a superset of the default -s functionality: -s adds the default signature, -s "x" adds signature "x" ... Users don't really care that one is implemented as a trailer and another isn't. In fact, default -s can be implemented as a trailer too, right?
Could you clarify please?
-- MST