git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [RFH] revision limiting sometimes ignored
Date: Mon, 4 Feb 2008 09:32:15 -0800 (PST)	[thread overview]
Message-ID: <alpine.LFD.1.00.0802040922480.3034@hp.linux-foundation.org> (raw)
In-Reply-To: <20080203043310.GA5984@coredump.intra.peff.net>



On Sat, 2 Feb 2008, Jeff King wrote:
> 
> OK, there is definitely a bug here, but I'm having some trouble figuring
> out the correct fix. It's in the revision walker, so I have cc'd those
> who are more clueful than I.

Ok, I agree that there is a bug, and your two-liner fix is a "fix" in that 
it works, but I think it's absolutely the wrogn fix because it is totally 
unacceptable from a performance angle. We obviously need to break out of 
the loop before we have walked the whole commit chain.

>  		if (obj->flags & UNINTERESTING) {
>  			mark_parents_uninteresting(commit);
> -			if (everybody_uninteresting(list))
> -				break;
>  			continue;
>  		}

So I think the real problem here is not that the logic is wrong in 
general, but that there is one *special* case where the logic to break out 
is wrong.

And that special case is when we hit the root commit which isn't negative.

That case is special because *normally*, if we have a positive commit, we 
will always continue to walk the parents of that positive commit, so the 
"everybody_interesting()" check will not trigger. BUT! If we hit a root 
commit and it is positive, that won't happen (since, by definition, it has 
no parents to keep the list populated with), and now we break out early.

So I think your fix is wrong, but it's "close" to right: I suspect that we 
can fix it by marking the "we hit the root commit" case, and just 
disabling it for that case.

This patch is untested and obviously won't even compile (I didn't actually 
add the "hit_root" bitfield to the revision struct), but shows what I 
*think* should fix this issue, without the performance problem.

But maybe I haven't thought it entirely through, and there is some other 
case that can trigger this bug.

So please somebody double-check my thinking.

			Linus

---
diff --git a/revision.c b/revision.c
index 6e85aaa..0e90988 100644
--- a/revision.c
+++ b/revision.c
@@ -456,6 +456,9 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit, str
 
 	left_flag = (commit->object.flags & SYMMETRIC_LEFT);
 
+	if (!commit->parents)
+		revs->hit_root = 1;
+
 	rest = !revs->first_parent_only;
 	for (parent = commit->parents, add = 1; parent; add = rest) {
 		struct commit *p = parent->item;
@@ -579,7 +582,7 @@ static int limit_list(struct rev_info *revs)
 			return -1;
 		if (obj->flags & UNINTERESTING) {
 			mark_parents_uninteresting(commit);
-			if (everybody_uninteresting(list))
+			if (!revs->hit_root && everybody_uninteresting(list))
 				break;
 			continue;
 		}

  parent reply	other threads:[~2008-02-04 17:34 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-02 12:21 [BUG?] git log picks up bad commit Tilman Sauerbeck
2008-02-03  3:00 ` Jeff King
2008-02-03  4:33   ` [RFH] revision limiting sometimes ignored Jeff King
2008-02-03  6:24     ` Junio C Hamano
2008-02-03  6:39     ` Junio C Hamano
2008-02-03  7:13       ` Jeff King
2008-02-03  7:18         ` Jeff King
2008-02-03  7:40           ` Junio C Hamano
2008-02-03  7:47             ` Junio C Hamano
2008-02-03  8:18           ` Junio C Hamano
2008-02-04 17:32     ` Linus Torvalds [this message]
2008-02-04 17:37       ` Linus Torvalds
2008-02-04 19:08       ` Junio C Hamano
2008-02-04 20:03         ` Linus Torvalds
2008-02-04 20:06           ` Linus Torvalds
2008-02-04 20:50           ` Linus Torvalds
2008-02-05  7:14             ` Junio C Hamano
2008-02-05 21:23               ` Linus Torvalds
2008-02-05 22:34                 ` Johannes Schindelin
2008-02-05 23:59                   ` Linus Torvalds
2008-02-06 16:43                     ` Tilman Sauerbeck
2008-02-06 17:28                       ` Nicolas Pitre
2008-02-06 17:42                         ` Linus Torvalds
2008-02-06 17:48                           ` Nicolas Pitre
2008-02-06 19:26                       ` Linus Torvalds
2008-02-06  1:22                   ` Nicolas Pitre
2008-02-06  1:51                   ` Junio C Hamano
2008-02-06  6:05                     ` Junio C Hamano
2008-02-06  6:17                       ` Junio C Hamano
2008-02-05 23:44                 ` Junio C Hamano
2008-02-06  0:52                   ` Linus Torvalds
2008-02-06  5:30                     ` Junio C Hamano
2008-02-06  8:16                       ` Karl Hasselström
2008-02-06 10:34                       ` Linus Torvalds

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=alpine.LFD.1.00.0802040922480.3034@hp.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /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).