From: Jeff King <peff@peff.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Pierre Habouzit <madcoder@debian.org>,
Git Mailing List <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [RFC] Re: Convert 'git blame' to parse_options()
Date: Tue, 24 Jun 2008 15:46:18 -0400 [thread overview]
Message-ID: <20080624194617.GA11862@sigill.intra.peff.net> (raw)
In-Reply-To: <alpine.LFD.1.10.0806241036560.2926@woody.linux-foundation.org>
On Tue, Jun 24, 2008 at 10:44:24AM -0700, Linus Torvalds wrote:
> And to solve that _single_ problem, I wanted parse_options() to be able
> to:
>
> - stop at unknown options (so that I could hand-parse them)
>
> - ignore unknown options (so that I could parse all the ones I knew
> about, and then either hand-parse the rest, or just pass them on to
> _another_ function that used some arbitrary model to parse the parts it
> knew about)
>
> See? Single issue.
OK, fair enough. You are working towards a single goal. But I think
there is a flaw with that one sub-part of your goal (specifically your
second bullet point). I don't care about the other parts, and in fact I
even said "this is a fine way of doing that".
> And I even sent out a single patch for it. That single patch, btw, was
> even rather small.
>
> Did you ever look at that patch? Did you ever look at the code I was
> trying to have use parse_options()? No.
How can you even say something so ridiculous? Were you sitting at my
computer all day yesterday, making sure I didn't read your patch? No?
Funnily enough, I was there. And guess what I saw? Yes, it was me
READING YOUR PATCH (in a mirror, of course).
But I don't expect you to have a camera installed over my shoulder. So I
guess you would have had to just content yourself with THE EMAILS WHERE I
MENTION YOUR PATCH AND ITS EFFECTS.
> You constantly try to change the discussion to be about SOMETHIGN ELSE.
>
> For example, you keep on bringing up this TOTAL RED HERRING:
>
> > - 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.
>
> NOBODY F*CKIGN CARES!
I care. Apparently Junio cared in the thread that I pointed out earlier.
Other commands that parse the options will care, if we are to ever port
them to parse_options. I understand that you don't care about those
things, and you only want git-blame to work. I am merely trying to help
amortize work that goes into fixing git-blame into helping to fix other
commands. To do that, I pointed out a flaw that might prevent the same
solution being used again.
I understand that you are interested in incremental change, and that
doing something now in git-blame is better than doing nothing while we
wait for a longer, more complete solution to arrive. But did I say "No,
we shouldn't apply this patch from Linus because it's not the optimal
solution?" No. Instead, I said "In the meantime, your patch does not
make this particular problem any worse."
> Because what builtin-blame.c *already* does is exactly that.
I KNOW AND I EVEN SAID THAT. But here it is in case you are hard of
hearing:
From 20080623195314.GA29569@sigill.intra.peff.net:
"In the meantime, I don't think your patch makes anything _worse_,
since we already have these sorts of bugs in the current parsing
code."
From 20080623183358.GA28941@sigill.intra.peff.net:
"It's worse than that...Try (with current git-blame...
$ git blame -n 1 git.gc
fatal: bad revision '1'
> This is what I'm complaining about with your totally IDIOTIC mails. You're
> ignoring reality, and talking about how things "ought to work", and never
> ever apparently looked at how things *do* work.
Again, how in the world can you say that I didn't look at how things do
work WHEN I CUT AND PASTED A SAMPLE TRANSCRIPT SHOWING HOW THEY DO WORK?
BTW, this is the third time you have mentioned the phrase "ought to
work" in a way that is totally disingenuous about what I actually said.
I can understand that perhaps I was not clear in the initial statement.
But I would have thought the other two times I explained it further
would have made it clear. So did you truly not understand my point, or
are you just being intentionally rude?
> The fact is, the one program I wanted to convert already does exactly what
> you claim is "impossible to be correct in all cases".
And it's not correct as it is now. And we have lived with it. Which is
why I didn't say "your proposal makes things worse." In fact, I said the
opposite.
> So either shut up, or send a patch to fix what you consider a bug. I'm
> waiting.
I already volunteered to work on it. I'm sorry that the patch didn't
materialize immediately, but I was working on other parts of git, just
as I mentioned when I said I would work on it.
In the meantime, I think Pierre has proposed an alternate approach that
also has promise, so I think it makes sense to see how he progresses
with that rather than potentially duplicate work.
And I will shut up now, because this is obviously getting nowhere. I
just find your responses so rude and misinformed not about technical
matters, but about my statements and my intent that I feel the need to
publicly defend myself.
-Peff
next prev parent reply other threads:[~2008-06-24 19:47 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-23 5:15 Convert 'git blame' to parse_options() Linus Torvalds
2008-06-23 6:35 ` Junio C Hamano
2008-06-23 12:28 ` Johannes Schindelin
2008-06-23 8:22 ` [RFC] " Pierre Habouzit
2008-06-23 12:26 ` Johannes Schindelin
2008-06-23 15:53 ` Pierre Habouzit
2008-06-23 16:25 ` Johannes Schindelin
2008-06-23 16:25 ` Linus Torvalds
2008-06-23 16:49 ` Jeff King
2008-06-23 17:06 ` Linus Torvalds
2008-06-23 17:15 ` Jeff King
2008-06-23 17:32 ` Linus Torvalds
2008-06-23 18:15 ` Jeff King
2008-06-23 18:36 ` Linus Torvalds
2008-06-23 18:20 ` Linus Torvalds
2008-06-23 18:33 ` Jeff King
2008-06-23 18:47 ` Linus Torvalds
2008-06-23 19:16 ` Linus Torvalds
2008-06-23 21:09 ` Pierre Habouzit
2008-06-23 21:11 ` [PATCH] parse-opt: have parse_options_{start,end} Pierre Habouzit
2008-06-23 21:11 ` [PATCH] parse-opt: Export a non NORETURN usage dumper Pierre Habouzit
2008-06-23 21:11 ` [PATCH] parse-opt: create parse_options_step Pierre Habouzit
2008-06-23 21:11 ` [PATCH] parse-opt: do not pring errors on unknown options, return -2 intead Pierre Habouzit
2008-06-23 21:11 ` [PATCH] parse-opt: fake short strings for callers to believe in Pierre Habouzit
2008-06-23 22:08 ` [PATCH] parse-opt: do not pring errors on unknown options, return -2 intead Junio C Hamano
2008-06-23 22:13 ` Pierre Habouzit
2008-06-23 21:23 ` [RFC] Re: Convert 'git blame' to parse_options() Pierre Habouzit
2008-06-23 21:23 ` Junio C Hamano
2008-06-23 21:28 ` Pierre Habouzit
2008-06-23 21:26 ` Linus Torvalds
2008-06-23 21:41 ` Linus Torvalds
2008-06-23 21:47 ` Pierre Habouzit
2008-06-23 22:11 ` Junio C Hamano
2008-06-23 22:24 ` Pierre Habouzit
2008-06-23 22:36 ` Pierre Habouzit
2008-06-23 22:38 ` Junio C Hamano
2008-06-23 23:31 ` Pierre Habouzit
2008-06-23 23:40 ` Linus Torvalds
2008-06-23 23:51 ` Junio C Hamano
2008-06-24 7:50 ` Pierre Habouzit
2008-06-24 1:27 ` Jeff King
2008-06-23 19:53 ` Jeff King
2008-06-23 20:04 ` Pierre Habouzit
2008-06-23 20:12 ` Linus Torvalds
2008-06-24 5:35 ` Jeff King
2008-06-24 16:59 ` Linus Torvalds
2008-06-24 17:13 ` Johannes Schindelin
2008-06-24 17:34 ` Jeff King
2008-06-24 17:44 ` Linus Torvalds
2008-06-24 19:46 ` Jeff King [this message]
2008-06-24 0:30 ` Junio C Hamano
2008-06-24 8:24 ` Pierre Habouzit
2008-06-24 17:05 ` Linus Torvalds
2008-06-24 19:30 ` Pierre Habouzit
2008-06-24 19:43 ` Pierre Habouzit
2008-06-25 6:09 ` Johannes Sixt
2008-06-23 17:04 ` Johannes Schindelin
2008-06-23 17:21 ` Linus Torvalds
2008-06-23 18:39 ` Johannes Schindelin
2008-06-23 17:26 ` Jeff King
2008-06-23 18:41 ` Johannes Schindelin
2008-06-23 19:24 ` Pierre Habouzit
2008-06-23 16:11 ` Linus Torvalds
2008-06-24 9:12 ` Making parse-opt incremental, reworked series Pierre Habouzit
2008-06-24 9:12 ` [PATCH 1/7] parse-opt: have parse_options_{start,end} Pierre Habouzit
2008-06-24 9:12 ` [PATCH 2/7] parse-opt: Export a non NORETURN usage dumper Pierre Habouzit
2008-06-24 9:12 ` [PATCH 3/7] parse-opt: create parse_options_step Pierre Habouzit
2008-06-24 9:12 ` [PATCH 4/7] parse-opt: do not pring errors on unknown options, return -2 intead Pierre Habouzit
2008-06-24 9:12 ` [PATCH 5/7] parse-opt: fake short strings for callers to believe in Pierre Habouzit
2008-06-24 9:12 ` [PATCH 6/7] parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option Pierre Habouzit
2008-06-24 9:12 ` [PATCH 7/7] Migrate git-blame to parse-option partially Pierre Habouzit
2008-06-24 10:03 ` [PATCH 6/7] parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option Pierre Habouzit
2008-06-24 17:18 ` Linus Torvalds
2008-06-24 19:27 ` Pierre Habouzit
2008-06-24 20:55 ` Pierre Habouzit
2008-06-24 17:20 ` [PATCH 5/7] parse-opt: fake short strings for callers to believe in Linus Torvalds
2008-06-24 19:26 ` Pierre Habouzit
2008-06-25 15:07 ` Andreas Ericsson
2008-06-24 20:58 ` [REPLACEMENT PATCH] " Pierre Habouzit
2008-06-26 8:35 ` Pierre Habouzit
2008-06-26 8:40 ` Junio C Hamano
2008-06-26 9:37 ` Pierre Habouzit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080624194617.GA11862@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=madcoder@debian.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).