Re: [PATCH] parse-options: deprecate OPT_BOOLEAN

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 28, 2011, 04:22 UTC
Message-ID: <7vbou5s3c0.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110928035809.GC10662@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 17 quoted lines

> On Tue, Sep 27, 2011 at 04:56:49PM -0700, Junio C Hamano wrote:
>
>> It is natural to expect that an option defined with OPT_BOOLEAN() could be
>> used in this way:
>> [...]
>> to easily tell three cases apart:
>> 
>>  - There is no mention of the `--option` on the command line;
>>  - The variable is positively set with `--option`; or
>>  - The variable is explicitly negated with `--no-option`.
>> 
>> Unfortunately, this is not the case. OPT_BOOLEAN() increments the variable
>> every time `--option` is given, and resets it to zero when `--no-option`
>> is given.
>
> Yes, please. I remember being bitten by this at one point. Your
> transition plan makes sense to me.

The best part of it is that this leaves many small bite-sized tasks, one "struct option" per patch, most of which can be done by people who are not uber experts in Git internals ;-).

> Can OPT_UYN be folded into this, as well?

Perhaps, but I would prefer to keep this simple at least during the first pass of eradicating OPT_BOOLEAN and OPTION_BOOLEAN. After that is done, we may want to tackle OPT_UYN() that uses 2 for "unset", which feels a tad unnatural. It has only one user---even if it turns out that it was a mistake, the damage would be relatively limited to fix it.