On Wed, Apr 19, 2017 at 12:29 AM, René Scharfe [off-list ref] wrote:

Am 18.04.2017 um 19:09 schrieb Ævar Arnfjörð Bjarmason:

quoted

Change various --no-OPT options which don't supply PARSE_OPT_NONEG to
make --no-no-OPT an error.

All of these worked before this change, e.g. doing cloning by doing
"git clone --no-no-checkout" is equivalent to just "git clone", but
this was never intended, and is inconsistent with other --no-OPT
options which do pass PARSE_OPT_NONEG.

First: Why does that bother you, i.e. what's the harm?

It's just unintended emergent behavior I noticed. I.e. I was hacking
up clone.c and wondering if --no-no-tags for my new --no-tags would
error out, it didn't, but it should.

Setting PARSE_OPT_NONEG takes away the ability to toggle the affected
option.  E.g. git clone would reject --checkout.  Currently users can
specify --no- options as defaults in aliases and override them on the
command line if needed, with the patch that won't be possible anymore.

PARSE_OPT_NONEG should only be used for options where a negation doesn't
make sense, e.g. for the --stage option of checkout-index.

That's a bad bug, I don't know whether to be surprised or not that we
had no tests for this :)

I thought I was just disabling --no-no-checkout for --no-checkout, not
--checkout, but didn't notice the subtleties of the special case
handling for --no-* in parse-options.c, thanks.

Also: https://public-inbox.org/git/4F4D3545.6060704@lsrfire.ath.cx/

Ah, so this whole thing has been discussed before & rejected. I'll
just drop it too and use OPT_BOOL() in v2 of my other patch. Thanks.