Jeff King [off-list ref] 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.
Hi,
On Tue, 17 Jun 2008, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
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.
AFAIR Pierre tried a few ways, and settled with a macro to introduce the
diff options into a caller's options.
IOW it would look something like this:
static struct option builtin_what_options[] = {
[... options specific to this command ...]
DIFF__OPT(&diff_options)
};
Ciao,
Dscho
On Wed, Jun 18, 2008 at 05:13:02AM +0000, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
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, and we
decided some time ago that it wasn't a good idea. 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.
That's why we settled for the other way Dscho pointed. But for that, I
need to work on it more than what I really have time to nowadays, and
moreover, it needs some things (the setup_revisions split and the log
traversal bits change) to be merged.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org