Re: [RFC PATCH] parse-options: disallow double-negations of options starting with no-
- Date: Wed, 19 Apr 2017 14:23:43 -0700
- From: Jacob Keller <jacob.keller@xxxxxxxxx>
- Subject: Re: [RFC PATCH] parse-options: disallow double-negations of options starting with no-
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
>>> 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.
> 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..?
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"