On Mon, Apr 11, 2016 at 09:09:48AM +0200, Matthieu Moy wrote: > "Michael S. Tsirkin" <mst@xxxxxxxxxx> 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? > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html