On Tue, Jun 24, 2008 at 09:59:47AM -0700, Linus Torvalds wrote:
> 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.
> 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
--
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
