From: Jeff King <peff@peff.net>
To: Pierre Habouzit <madcoder@debian.org>
Cc: "Junio C Hamano" <gitster@pobox.com>,
sverre@rabbelier.nl, "Björn Steinbrink" <B.Steinbrink@gmx.de>,
"Stephen R. van den Berg" <srb@cuci.nl>,
"Git Mailinglist" <git@vger.kernel.org>
Subject: Re: git blame not respecting --find-copies-harder ?
Date: Thu, 31 Jul 2008 05:34:10 -0400 [thread overview]
Message-ID: <20080731093410.GA21396@sigill.intra.peff.net> (raw)
In-Reply-To: <20080731091515.GC12867@artemis.madism.org>
[Pierre, you have the bogus MFT header that people are often complaining
about. Either I have to do extra work to fix the headers, or more people
end up in the To: field. I don't personally care about the latter, but
it seems that others organize their mail based on To versus Cc]
On Thu, Jul 31, 2008 at 11:15:15AM +0200, Pierre Habouzit wrote:
> --no-walk alters how add_pending_object_with_mode works, which is called
> by handle_revision_arg. IOW, <ref1> --no-walk <ref2> is not the same as
> --no-walk <ref1> <ref2>. IOW reference arguments and --no-walk ordering
> must be preserved, IOW --no-walk is a pseudo-argument like --all --tags
> or --remote are.
Ah, OK. Then that makes sense, then. And I definitely feel that the
patch I posted is the right thing to do, then. So here is a patch with
commit message. The commit message to patch ratio is ridiculous, but
obviously this fix took some thinking, so it seems best to document it.
-- >8 --
allow "non-option" revision options in parse_option-enabled commands
Commands which use parse_options but also call
setup_revisions must do their parsing in a two step process:
1. first, they parse all options. Anything unknown goes to
parse_revision_opt (which calls handle_revision_opt),
which may claim the option or say "I don't recognize
this"
2. the non-option remainder goes to setup_revisions to
actually get turned into revisions
Some revision options are "non-options" in that they must be
parsed in order with their revision counterparts in
setup_revisions. For example, "--all" functions as a
pseudo-option expanding to all refs, and "--no-walk" affects
refs after it on the command line, but not before. The
revision option parser in step 1 recognizes such options and
sets them aside for later parsing by setup_revisions.
However, the return value used from handle_revision_opt
indicated "I didn't recognize this", which was wrong. It
did, and it took appropriate action (even though that action
was just deferring it for later parsing). Thus it should
return "yes, I recognized this."
Previously, these pseudo-options generated an error when
used with parse_options parsers (currently just blame and
shortlog). With this patch, they should work fine, enabling
things like "git shortlog --all".
Signed-off-by: Jeff King <peff@peff.net>
---
revision.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/revision.c b/revision.c
index a843c42..eaa5572 100644
--- a/revision.c
+++ b/revision.c
@@ -1002,7 +1002,7 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
!strcmp(arg, "--no-walk") || !strcmp(arg, "--do-walk"))
{
unkv[(*unkc)++] = arg;
- return 0;
+ return 1;
}
if (!prefixcmp(arg, "--max-count=")) {
--
1.6.0.rc1.197.gc57ac6
next prev parent reply other threads:[~2008-07-31 9:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-30 9:39 git blame not respecting --find-copies-harder ? Stephen R. van den Berg
2008-07-30 15:01 ` Björn Steinbrink
2008-07-30 15:43 ` Sverre Rabbelier
2008-07-31 6:48 ` Jeff King
2008-07-31 7:05 ` Junio C Hamano
2008-07-31 7:21 ` Jeff King
2008-07-31 7:36 ` Junio C Hamano
2008-07-31 8:25 ` Jeff King
2008-07-31 8:35 ` Junio C Hamano
2008-07-31 9:01 ` Pierre Habouzit
2008-07-31 9:05 ` Jeff King
2008-07-31 9:06 ` Pierre Habouzit
2008-07-31 9:03 ` Jeff King
2008-07-31 9:15 ` Pierre Habouzit
2008-07-31 9:34 ` Jeff King [this message]
2008-07-31 10:22 ` Pierre Habouzit
2008-07-31 10:33 ` Jeff King
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=20080731093410.GA21396@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=B.Steinbrink@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=madcoder@debian.org \
--cc=srb@cuci.nl \
--cc=sverre@rabbelier.nl \
/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).