On Wed, Apr 19, 2017 at 2:22 PM, Jacob Keller <jacob.keller@xxxxxxxxx> wrote: > On Wed, Apr 19, 2017 at 2:00 PM, Jeff King <peff@xxxxxxxx> wrote: >> On Wed, Apr 19, 2017 at 01:54:06PM -0700, Jacob Keller wrote: >> >>> This is why it's an RFC. I don't really feel that it's too much of a >>> problem. As for the reason why I thought it might want a flag itself >>> is because of concerns raised earlier that we might have something >>> liek >>> >>> OPT_BOOL( ... "no-stage" ...) >>> OPT_INT(... "stage" ....) >>> >>> or something already which might be broken and the only proper way to >>> disable no-stage is no-no-stage? >>> >>> Is this actually a concern? I thought this was a comment raised by you >>> earlier as an objection to a change unless we specifically flagged >>> them as OPT_NEGBOOL() >> >> I think the breakage in that case would be caused by "--no-stage" taking >> over "--stage" as well. And your patch doesn't change that; it happened >> already in 2012. >> >> Your patch only affects the --no-no- form, which I think we would never >> want. I don't think it needs callers to trigger it explicitly. >> >> -Peff > > Right, I was just thinking in the weird cause were we *do* have a > "no-option" that does want the "no-no-option" to negate it. Maybe this > isn't ever a thing and we don't need to worry at all..? > > Thanks, > Jake And in this case the same PARSE_OPT_FLAG would be used to also not do the "no-option" negates to "option" as well, since the options point would be something liek "this option starts with no- but negates normally even though we don't normally allow that"