Re: git interpret-trailers with multiple keys

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Sun, Apr 10, 2016 at 06:57:53PM +0200, Christian Couder wrote:
>> What I meant is that we could create new options called maybe
>> trailer.autocommands and trailer.<token>.autocommands that default to
>> 'true' and if 'false' the command would not be run automatically and
>> the corresponding trailer would not be added.
>
> I don't think it has to do with commands.
> For example, if we add "value" it should behave the same.
>
> So I think a better name is "ifnotlisted", with values "add"
> and "donothing".

Having a negation in the variable name feels wrong. When the token is
listed on the command-line and ifnotlisted=donothing, I have to apply a
double-negation to guess what would happen (=> "if listed then do
something").

I agree that having such variable would be a good thing. It would solve
your issue (i.e. "How to I configure a token for quick use from the
command-line without applying it unconditionally"), and allow full
backward compatibility.

I'd call the option "apply" or perhaps "run", with values 1/true/always
= default = current behavior, or "auto" = "apply when asked from the
command-line". I'm wondering whether other values could make sense (not
to implement it right now, but to keep the design open to further
extensions): perhaps apply=ifauthor could mean "apply this trailer to
patches I'm the author of" for example.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/