Re: [PATCH] various: disallow --no-no-OPT for --no-opt options

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Apr 19, 2017, 07:00 UTC
Message-ID: <CACBZZX6XWXjvDKeR+a1Ymb4csXgOKLiF==VkKLp5S9TRVQhgoA@mail.gmail.com>
In-Reply-To: <de79d366-3609-8efe-b23a-7e793036b3ef@web.de>

On Wed, Apr 19, 2017 at 12:29 AM, René Scharfe <l.s.r@web.de> wrote:

Show 12 quoted lines

> Am 18.04.2017 um 19:09 schrieb Ævar Arnfjörð Bjarmason:
>>
>> 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.

Show 7 quoted lines

> 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.