Re: [PATCH] parse-options: warn developers on negated options

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 6, 2017, 01:52 UTC
Message-ID: <xmqq8thsa901.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170905230845.17108-1-sbeller@google.com>

Stefan Beller <sbeller@google.com> writes:

>   This patch disallows all no- options, but we could be more open and allow
>   --no-options that have the NO_NEG bit set.

"--no-foo" that does not take "--foo" is perhaps OK so should not trigger an error.

A ("--no-foo", "--foo") pair is better spelled as ("--foo", "--no-foo") pair whose default is "--foo", but making it an error is probably a bit too much.

Compared to that, ("--no-foo", "--no-no-foo") pair feels nonsense.

Having said that, because the existing parse_options_check() is all about catching the programming mistake (the end user cannot fix an error from it by tweaking the command line option s/he gives to the program), I do not think a conditional compilation like you added mixes well. Either make the whole thing, not just your new test, conditional to -DDEVELOPER (which would make it possible for you to build and ship a binary with broken options[] array to the end-users that does not die in this function), which is undesirable, or add a new test that catches a definite error unconditionally.