Re: [PATCH 1/4] parse-options: allow git commands to invent new option types

Stephen Boyd wrote:

Is there an actual use case where someone needs to completely override
get_value()? If you move this into the case statement then we get the
generic error checking of get_value() with the benefits of being able to
modify the context within a callback.

Yes, I like this idea.

We could also probably use the
return value of the low level callback to indicate whether or not to
take some action after parsing the option. Perhaps something like
quiting the option parsing loop when encountering such an option?

I'd rather not, since that would involve anticipating needs in advance.
This is meant to be a back door for ugly and unusual option types that
the mainstream API does not take care of yet.  It seems best to allow
arbitrary effects.

[...]

quoted

-#define OPT_SHORT 1
-#define OPT_UNSET 2

[...]

quoted

+++ b/parse-options.h

@@ -40,8 +41,16 @@ enum parse_opt_option_flags {
 	PARSE_OPT_SHELL_EVAL = 256
 };
 
+enum parse_opt_ll_flags {
+	OPT_SHORT = 1,
+	OPT_UNSET = 2
+};
+

I hope this isn't necessary.

Because of namespace or something else?

This reminds me, we can probably simplify that "takes no value" error
path in get_value() (see below).

Nice.

Thanks,
Jonathan