Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 7, 2014, 19:20 UTC
Message-ID: <xmqqzjl1u87n.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CACsJy8AUhHE8=Yaj6_G46V6w5ZbA3z403GkBfsbZL7MxgeA3RQ@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

> I don't know the scope of these microprojects, but yes I think it'll
> take a few hours for this. By the way, a bit more thought on the idea:
> instead of making OPT_BOOL_NONEG() that sets NONEG, we could make
> OPT_BOOL_FLAGS(..., NONEG), which is more flexible.

What does a boolean that can never be set to false achieve, by the way? If you have

    [alias]
        foo = bar --frotz

then you may want to be able to say "git foo --no-frotz" to countermand the frotz option, and by marking the boolean frotz option to be a NONEG, you can forbid such a usage. That is the only "use case" I can think of, and that particular use case does not sound like a valid one.

Looking at "git grep -B3 OPT_NONEG" output, it seems that NONEG is associated mostly with OPTION_CALLBACK and OPTION_SET_INT in the existing code.

Perhaps OPT_SET_INT should default to not just OPT_NOARG but also OPT_NONEG?

I have a suspition that most users of other OPT_SET_<TYPE> short-hands may also want them to default to NONEG (and the rare ones that want to allow "--no-value-of-this-type=Heh" for some reason to use the fully spelled form). IIRC NONEG is relatively a new addition, and many existing OPT_STRING() may predate it.

So I am not sure if doubling the number of OPT_<type> macros as your micro suggestion proposes is the right solution to the problem.