Pierre Habouzit <madcoder@xxxxxxxxxx> writes: > On Wed, Jun 18, 2008 at 05:13:02AM +0000, Junio C Hamano wrote: >> Jeff King <peff@xxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
