On Wed, Apr 19, 2017 at 12:29 AM, René Scharfe <l.s.r@xxxxxx> wrote: > 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. > 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@xxxxxxxxxxxxxx/ 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.