Re: Microproject idea: new OPT_* macros for PARSE_OPT_NONEG

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Duy Nguyen <pclouds@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]