[RFC] Re: Convert 'git blame' to parse_options()

On Mon, Jun 23, 2008 at 05:15:41AM +0000, Linus Torvalds wrote:

You can't, mainly because of option aggregation: if the parser1 knows about -a and -b, parser2 about -c, then, this kind of things is problematic: -acb because you need to go to the parser '2' to know about -c, and you can't filter the arguments and keep -c and give -b to parser1 again, *BECAUSE* 'b' could also be -c argument.

This "PARSE_OPT_IGNORE_UNRECOGNIZED" thing has been discussed many times in the past, but it just doesn't fly.

Though to help migrations we can probably introduce a new parse option construct that would be a callback that is responsible for dealing with "things" the upper level parser doesn't know about, something where the callback could be:

enum {
    FLAG_ERROR = -1,
    FLAG_NOT_FOR_ME,
    FLAG_IS_FOR_ME,
    FLAG_AND_VALUE_ARE_FOR_ME,
}

int (*parse_opt_unknown_cb)(int shortopt, const char *longopt,
                            const char *value, void *priv);

Where the callback is supposed to work that way: we pass to it either a shortopt ('\0' else) or a longopt (NULL else) but never both, and what the parser could find as a possible value in value (NULL if no value found). Then the parser does what it has to, and returns one of the previous enum values. ERROR would be a fatal error (-1 chosen so that one can return error(...)), NOT_FOR_ME if it didn't want the flag after all, IS_FOR_ME if it took only the flag, without the value, the last one being if it consumed both the option flag _and_ the value.

Of course for things like --long-opt=value if the callback doesn't eat the value, then parse_options would have to barf loudly.

The major drawback of this method is that parse_options won't generate the nice usage help for the things that recurse in such a function. But at least it eases migration to parseoptions, because I believe rev_parse and diff_opt_parse to be _way_ easier to migrate to such a callback _and_ with the old API together (I really believe that the old big consuming loops could use such a callback directly e.g.) so that commands using diff and revision options can be migrated to parse-opt *slowly* rather than all at a time (which is a no-go and is such a big amount of work that I avoided it in despair).

If people believe it's a sane approach I can do it. I absolutely don't know why no one thought of that before, but I don't see any major drawback (except for the "help" bits, but like I said, it's a "code upgrade path" and not meant to be the final state).