Microproject idea: new OPT_* macros for PARSE_OPT_NONEG

Currently in order to avoid --[no]-xxx form we have to resort to declare full struct option. It'd be nice to have a set of OPT_* macros with PARSE_OPT_NONEG set. Find and update all "struct option []" declarations with the new macros (including ones that should never accept --no- form, but do anyway).

On 03/07/2014 02:38 AM, Duy Nguyen wrote:

I added this to the list, with the following warning:

    This is more a milliproject than a microproject

because to me it feels considerably more involved than the other microprojects. To complete it, the student will have to understand at least part of the parse_options() API, which is more than a 15 minute job by itself.

Thanks, Michael

On Fri, Mar 7, 2014 at 2:39 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:

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.

Duy Nguyen <pclouds@gmail.com> writes:

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.

On Sat, Mar 8, 2014 at 2:20 AM, Junio C Hamano <gitster@pobox.com> wrote:

There are OPT_SET_INT() that should not have NONEG in current code. So there are two sets of SET_INT anyway. Either we convert them all to a new macro that takes an extra flag, or we add OPT_SET_INT_NONEG() that covers one set and leave the other set alone.

I haven't checked how NONEG affects other types. But that's something I should probably look into.

Duy Nguyen <pclouds@gmail.com> writes:

Are you forgetting the third alternative, of swapping the default, if the ones that do not want NONEG are in the minority, to reduce the number of spelled-out instances?

On Fri, Mar 14, 2014 at 2:00 AM, Junio C Hamano <gitster@pobox.com> wrote:

There are 12 SET_INT with NONEG and 81 without (though I suspect some of them should have NONEG). So NONEG is not exactly the majority. And swapping does not go well with git development style, some in-flight topics may introduce new OPT_SET_INT() that uses the old behavior.