"Michael S. Tsirkin" <m...@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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
