Re: [RFC PATCH] parse-options: disallow double-negations of options starting with no-

From: Jacob Keller <jacob.keller@gmail.com>
Date: Apr 19, 2017, 21:22 UTC
Message-ID: <CA+P7+xpahRim9H1cHuHmzjGggYt2qbvxrDYyi+ri0QsDEUAkcw@mail.gmail.com>
In-Reply-To: <20170419210028.sky24qda7kp4pl5y@sigill.intra.peff.net>

On Wed, Apr 19, 2017 at 2:00 PM, Jeff King <peff@peff.net> wrote:

Show 25 quoted lines

> 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