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@xxxxxxxxxx> 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@xxxxxxxxxx>" --trailer "Reviewed-by: Michael S. Tsirkin > >> <mst@xxxxxxxxxx>" --trailer "Tested-by: Michael S. Tsirkin > >> <mst@xxxxxxxxxx>" 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@xxxxxxxxxx>" --trailer "r: Michael S. Tsirkin <mst@xxxxxxxxxx>" > >> --trailer "t: Michael S. Tsirkin <mst@xxxxxxxxxx>" 0001-foo.patch > >> >to_apply/0001-foo.patch > >> > >> And if you use an env variable: > >> > >> $ ME="Michael S. Tsirkin <mst@xxxxxxxxxx>" > >> $ 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@xxxxxxxxxx>" > >> $ git config trailer.r.defaultvalue "Michael S. Tsirkin <mst@xxxxxxxxxx>" > >> $ git config trailer.t.defaultvalue "Michael S. Tsirkin <mst@xxxxxxxxxx>" > > > > 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@xxxxxxxxx>" would add: > > Acked-by: Junio <gitster@xxxxxxxxx> > > while "--trailer a" would add: > > Acked-by: Michael S. Tsirkin <mst@xxxxxxxxxx> > > > Can't I define the whole 'Acked-by: Michael S. Tsirkin <mst@xxxxxxxxxx>' > > string as the key? > > The whole 'Acked-by: Michael S. Tsirkin <mst@xxxxxxxxxx>' 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html