On Mon, Jun 23, 2008 at 10:32:21AM -0700, Linus Torvalds wrote:

quoted text
> > 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.

How do you know that is the case, unless you know what the other option
parsers are going to do? Or are you suggesting that I check every other
downstream option parser to make sure that it's OK in this particular
instance, use IGNORE_UNKNOWN, and then laugh maniacally when somebody
adds such an option to the diff option parser later?

quoted text
> 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.

Reality: revision.c, lines 1008-1012. "-n" takes an argument.
Reality: revision.c, lines 1075-1080. "--default" takes an argument.

quoted text
> Try just looking at the code!

I did. Or maybe you missed the thread where this exact feature was
mentioned, and I already looked at the code and mentioned those two
spots. It's right here:

  http://thread.gmane.org/gmane.comp.version-control.git/85354/focus=85355

quoted text
> 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.

There is already a discussion underway about the proper solution. This
isn't just a git-blame issue, but rather an issue with all commands that
have their own options and take revision parameters. So I think rather
than doing a halfway fix that happens to work with git-blame, it is more
useful to focus on a solution that works everywhere and fix _all_ of the
problems.

-Peff
--
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