On Mon, 23 Jun 2008, Jeff King wrote: > > I'm not so sure. I assumed that most of the callbacks would simply take > a "struct rev_list". So you would end up in builtin-blame.c with: > > ... > OPT__REVISION(&my_rev_list), > ... > > in your options table. And if setup_revisions takes options that affect > things that _aren't_ in that struct, then they probably ought to be. The world isn't like "it ought to be". It is like it is. If you keep on dreaming about how things "ought to be", you'll never confront the things as they are. The fact is, turning the existing very simple argument parsers into using "parse_options()" is just _hard_. Then you say that it all "ought to be" in those options already. Sure. Do we have some invisible sky wizard to make it so? The thign is, parse_options() was introduced 8 months ago or so. Have you looked at the output of git grep 'str[n]*cmp.*"--' lately? Yes, they probably all "ought to be" something or other, but as it is, the fact is that they are a damn pain to convert. I tried to do just _one_ program. Trust me, I'm not going to even bother trying to do another unless parse_options() is made more palatable to do in small pieces. Linus -- 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
