Re: git interpret-trailers with multiple keys
- From
Matthieu Moy <matthieu.moy@grenoble-inp.fr>
- Date
- Apr 11, 2016, 07:09 UTC
- Message-ID
- <vpqegac7hab.fsf@anie.imag.fr>
- In-Reply-To
- <20160410203556-mutt-send-email-mst@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
Show 11 quoted lines
> 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/