On Mon, 23 Jun 2008, Jeff King wrote: > > How can that be correct, if you don't know whether "-b" takes an > argument? Did you read my post or not? If you have that case, then use STOP_ON_UNKNOWN. > That is the only thing that makes sense to me, since the command line > has to be parsed left-to-right (because the syntactic function of an > element relies on the semantics of the element to its left). Umm. Helloo, reality.. There are actually very few options that take a flag for their arguments. In particular, the option parsing we really _care_ about (revision parsing - see builtin-blame.c which is exactly where I wanted to convert things) very much DOES NOT. And that CONTINUE_ON_UNKNOWN behaviour is not some kind of theoretical flag. It's the flag that builtin-blame.c *wants*. It's the flag that describes hat builtin-blame.c does right now in the current git master branch. Try just looking at the code! So I'm really not interested in arguing about "theoretical issues", when we have a real-life *practical* issue to solve. Solve builtin-blame.c for me. I sent out a patch yesterday, but in the description of that patch I also described exactly why I want CONTINUE_ON_UNKNOWN. So can we please stop the clusterfuck now? 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
