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

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Sep 24, 2014 at 12:00:40PM +0200, Christian Couder wrote:
> On Tue, Sep 23, 2014 at 10:07 AM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Tue, Sep 23, 2014 at 09:45:50AM +0200, Christian Couder wrote:
> >> 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
> >>
> >> 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
> >
> > I would like multiple keys to match a specific
> > letter, e.g. as a maintainer I need
> > both reviewed by and signed off by when I
> > apply a patch, I like applying them with
> > a single "-s m".
> 
> That's different from what you implemented in your patch.
> And franckly I think that for this kind of specific use cases, you
> could create your own aliases, either Git aliases or just shell
> aliases.
> 
> For example if we implement default values and make git am call git
> interpret-trailers, a shell alias could simply be:
> 
> alias gamsm='git am --trailer r --trailer s'
> 
> I use "git log --oneline --decorate --graph" very often, so I made my
> own alias for it, and I suppose a lot of other people have done so.
> 
> The number of people who will use trailers will probably be much
> smaller than the number of people using git log, so if we don't make
> shortcuts for "git log --oneline --decorate --graph", I see no ground
> to ask for a specific shortcut that adds both a reviewed by and a
> signed off by.

I've been thinking: how about a generic ability to add option shortcuts
for commands in .config?
For example:

[am "-z"]
	command = "--trailer foobar"

would replace any -z in git am command line with --trailer foobar.


Does this sound useful?


> >> the first command could be simplified to:
> >>
> >> $ git interpret-trailers --trailer "a: Michael S. Tsirkin
> >> <mst@redhat.com>" --trailer "r: Michael S. Tsirkin <mst@redhat.com>"
> >> --trailer "t: Michael S. Tsirkin <mst@redhat.com>" 0001-foo.patch
> >> >to_apply/0001-foo.patch
> >>
> >> And if you use an env variable:
> >>
> >> $ ME="Michael S. Tsirkin <mst@redhat.com>"
> >> $ git interpret-trailers --trailer "a: $ME" --trailer "r: $ME"
> >> --trailer "t: $ME" 0001-foo.patch >to_apply/0001-foo.patch
> >>
> >> Maybe later we will integrate git interpret-trailers with git commit,
> >> git am and other commands, so that you can do directly:
> >>
> >> git am --trailer "a: $ME" --trailer "r: $ME"  --trailer "t: $ME" 0001-foo.patch
> >>
> >> Maybe we wil also assign a one letter shortcut to --trailer, for
> >> example "z", so that could be:
> >>
> >> git am -z "a: $ME" -z "r: $ME"  -z "t: $ME" 0001-foo.patch
> >
> > -s could apply here, right?
> 
> I don't know what we will do with -s. Maybe if we use -z, we don't need -s.
> 
> > It doesn't have a parameter at the moment.
> 
> We will have to discuss that kind of thing when we make it possible
> for git commit, git am and maybe other commands to accept trailers
> arguments and pass them to git interpret-trailers.
> 
> In his email Junio seems to say that we don't need a shortcut like -z,
> we could only have --trailer.
> And I think that it is indeed sound to at least wait a little before
> using up one shortcut like -z in many commands.
> 
> >> We could also allow many separators in the same -z argument as long as
> >> they are separated by say "~",
> >
> > I think -z a -z r -z t is enough.
> 
> Great! I think you will likely have at least "--trailer a --trailer r
> --trailer t", but I don't think it is too bad as you can use aliases
> to make it shorter to type.
> 
> >> so you could have:
> >>
> >> git am -z "a: $ME~r: $ME~t: $ME" 0001-foo.patch
> >>
> >> And then we could also allow people to define default values for
> >> trailers with something like:
> >>
> >> $ git config trailer.a.defaultvalue "Michael S. Tsirkin <mst@redhat.com>"
> >> $ git config trailer.r.defaultvalue "Michael S. Tsirkin <mst@redhat.com>"
> >> $ git config trailer.t.defaultvalue "Michael S. Tsirkin <mst@redhat.com>"
> >
> > I'm kind of confused by the key/value concept.
> 
> A "defaultvalue" would be the value used when no value is passed.
> The "key" is just what we will use in the first part of the trailer
> (the part before the separator).
> 
> For example with the above "defaultvalue" and "key", "--trailer a:
> Junio <gitster@pobox.com>" would add:
> 
> Acked-by: Junio <gitster@pobox.com>
> 
> while "--trailer a" would add:
> 
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> 
> > Can't I define the whole 'Acked-by: Michael S. Tsirkin <mst@redhat.com>'
> > string as the key?
> 
> The whole 'Acked-by: Michael S. Tsirkin <mst@redhat.com>' is a full
> trailer, not a "key".
> 
> And it is not possible right now to define a full trailer. Maybe we
> could find a way to make it possible, but a default value and a way to
> have a small nickname for the token (like "a" for "Acked-by") should
> get people quite far. And then for very specific use cases, it may be
> better to use aliases anyway.
> 
> >> So that in the end you could have:
> >>
> >> git am -z a~r~t 0001-foo.patch
> >>
> >> which is very close to "git am -s art".
> >
> > If I figure out the defaultvalue thing, I might
> > find the time to work on git am integration.
> 
> That would be great!
> 
> Thanks,
> Christian.