Re: [RFC] Re: Convert 'git blame' to parse_options()

From: Jeff King <peff@peff.net>
Date: Jun 24, 2008, 17:34 UTC
Message-ID: <20080624173428.GA9500@sigill.intra.peff.net>
In-Reply-To: <alpine.LFD.1.10.0806240954150.2926@woody.linux-foundation.org>

On Tue, Jun 24, 2008 at 09:59:47AM -0700, Linus Torvalds wrote:

Show 10 quoted lines

> I have a _single_ problem I have with parse_options(), namely that it was 
> painful to convert in pieces. It may well be that builtin-blame.c was one 
> of the more painful cases, but it really was a _single_ issue.
> 
> I also had a _single_ fix for it.
> 
> I never had "other" problems.
>
> What happened was that you and Dscho and others then tried to pick that 
> _single_ issue apart, because the solutions _you_ wanted (tying all the

Perhaps I was confused about the definition of "single", because throughout this thread you seem to be making multiple complaints about parse_options, including its lack of a "stop on unknown" flag, a "continue on unknown flag", and the movement of arguments within the argv array.

But whether you want to call that a "single" problem or not, my point was that I am not talking about most of those things.

So I will say one last time, as clearly as I possibly can, what I was trying to bring to the discussion:

  - You proposed a CONTINUE_ON_UNKNOWN type of flag.

  - It is impossible for that mechanism to be correct in all cases, due
    to the syntactic rules for command lines. IOW, you cannot parse an
    element until you know the function of the element to the left.

  - I wanted to mention it specifically, because that exact mechanism
    had already been proposed in a patch last week, and Junio said "this
    conceptually is broken".

  - There has been discussion underway about what is the best mechanism
    to solve the same situation.

That is the entirety of my point. I am glad you are trying to increase parse_options uptake. There is obviously a problem with multi-stage parsers. I talked about one way for them to be handled. I think there are multiple ways of going about it. It looks like STOP_ON_UNKNOWN is the way that Pierre is pursuing. I think this is good, because it doesn't suffer from the corner cases that CONTINUE_ON_UNKNOWN does.

And now I will stop making these points, because I don't think I am capable of saying them any more clearly than I already have, and because Pierre seems to be moving in a sane direction.

Show 5 quoted lines

> And then you talk about how things "ought to be" in your world, to make 
> your solution relevant at all.
> 
> And I'm trying to tell you that "ought to be" has no relevance, because 
> you're not even looking at the problem!

Again, did you even read the mail you are responding to? The phrase "ought to be" was totally incidental to the point I was making. I could just as easily have said "and this is the method that I think will be acceptable for dealing with this problem." But for some reason you insist on harping on the phrase as if I have proposed magical fairies should come work on the code, and totally ignoring the actual points that were made.

-Peff