From: Junio C Hamano Date: Wed, 28 Sep 2011 04:22:55 GMT Subject: Re: [PATCH] parse-options: deprecate OPT_BOOLEAN Message-ID: <7vbou5s3c0.fsf@alter.siamese.dyndns.org> In-Reply-To: <20110928035809.GC10662@sigill.intra.peff.net> Jeff King writes: > 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.