Re: [PATCH 2/3] parse-options: allow positivation of options starting, with no-

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 27, 2012, 17:18 UTC
Message-ID: <7v8vjob3ff.fsf@alter.siamese.dyndns.org>
In-Reply-To: <87d390smpa.fsf@thomas.inf.ethz.ch>

Thomas Rast <trast@inf.ethz.ch> writes:

Show 10 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> I would naïvely expect that it would be sufficient to update an existing
>> definition for "--no-frotz" that uses PARSE_OPT_NONEG to instead define
>> "--frotz" that by itself is a no-op, and "--no-frotz" would cause whatever
>> the option currently means, with an update to the help text that says
>> something to the effect that "--frotz by itself is meaningless and is
>> always used as --no-frotz".
>
> Doesn't that last quote already answer your question?

Yes, but only partly.  I would agree with the awkwardness in

> It would be rather awkward to see, in 'git apply -h',
>
>   --add                 Also apply additions in the patch.  This is the
>                         default; use --no-add to disable it.

but it feeels somewhat questionable that the solution to get this:

>
> Compare to the current concise wording
>
>   --no-add              ignore additions made by the patch

is to define OPT_BOOL("no-add") that does not have any hint (other than the fact that the option name begins with 3 character "no-") that this is an already negated boolean and the "no-" negation can be removed.

This means an option "no-$foo" can never mean anything but "not foo". Not that we would have to or necessarily want to support an option to give the number of foo as --no-foo=47, as --num-foo=47 is a perfectly good spelling for such an option.

If it were OPT_BOOL("no-foo", OPT_ISNEG | ...) that signals the parser that:

 - the option name is already negative;
 - the leading "no-" is to be removed to negate it; and
 - no extra leading "no-", i.e. "--no-no-foo", is accepted.

I probably wouldn't have felt this uneasy iffiness.

But it is just a minor issue.