Re: [RFC PATCH] parse-options: disallow double-negations of options starting with no-
- Date: Wed, 19 Apr 2017 14:22:47 -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: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..?