Re: git interpret-trailers with multiple keys
On Mon, Apr 11, 2016 at 09:09:48AM +0200, Matthieu Moy wrote:
Show 18 quoted lines
> "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").
Isn't this similar to ifmissing?
Show 15 quoted lines
> 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/