Thomas Rast <trast@xxxxxxxxxxx> writes:
> Junio C Hamano <gitster@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html