Pierre Habouzit <madcoder@debian.org> writes:

quoted text
> On Wed, Jun 18, 2008 at 05:13:02AM +0000, Junio C Hamano wrote:
>> Jeff King <peff@peff.net> writes:
>> 
>> > I think the only right way to accomplish this is to convert the revision
>> > and diff parameters into a parseopt-understandable format.
>> 
>> Not necessarily.  You could structure individual option parsers like how
>> diff option parsers are done.  You iterate over argv[], feed diff option
>> parser the current index into argv[] and ask if it is an option diff
>> understands, have diff eat the option (and possibly its parameter) to
>> advance the index, or allow diff option to say "I do not understand this",
>> and then handle it yourself or hand it to other parsers.
>
> If you do that, you need to relocate pars option structures,...
> ... Note that "recursing"
> is not really trivial, because with flags aggregation and stuff like
> that, things that look like an option can also be a value in the context
> of an other option parser.

Note that I was just saying "not necessarily" in response to "the only
right way" to point out it is not the _only_ way.

Parse-options has been done in a tablish way and it would involve cost to
modify it in a way I outlined (even if such a rewrite would make chaining
different set of option parsers easier, as each parser needs to handle
only what it knows about and handling aggregation and stuff would become
trivial).  I do not know if it is worth the cost, and I am not married to
the option parser structure that diff and revision part uses.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html