git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFH] revision limiting sometimes ignored

From
Linus Torvalds <torvalds@linux-foundation.org>
Date
Feb 4, 2008, 17:32 UTC
Message-ID
<alpine.LFD.1.00.0802040922480.3034@hp.linux-foundation.org>
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.

Show 6 quoted lines
>  		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;
 		}
Previous: Junio C HamanoNext: Linus Torvalds
Message 11 of 34 in “[BUG?] git log picks up bad commit”
  1. Tilman SauerbeckFeb 2, 2008
  2. Jeff KingFeb 3, 2008
  3. [RFH] revision limiting sometimes ignoredJeff King, Feb 3, 2008
  4. Junio C HamanoFeb 3, 2008
  5. Junio C HamanoFeb 3, 2008
  6. Jeff KingFeb 3, 2008
  7. Jeff KingFeb 3, 2008
  8. Junio C HamanoFeb 3, 2008
  9. Junio C HamanoFeb 3, 2008
  10. Junio C HamanoFeb 3, 2008
  11. Linus TorvaldsFeb 4, 2008
  12. Linus TorvaldsFeb 4, 2008
  13. Junio C HamanoFeb 4, 2008
  14. Linus TorvaldsFeb 4, 2008
  15. Linus TorvaldsFeb 4, 2008
  16. Linus TorvaldsFeb 4, 2008
  17. Junio C HamanoFeb 5, 2008
  18. Linus TorvaldsFeb 5, 2008
  19. Johannes SchindelinFeb 5, 2008
  20. Linus TorvaldsFeb 5, 2008
  21. Tilman SauerbeckFeb 6, 2008
  22. Nicolas PitreFeb 6, 2008
  23. Linus TorvaldsFeb 6, 2008
  24. Nicolas PitreFeb 6, 2008
  25. Linus TorvaldsFeb 6, 2008
  26. Nicolas PitreFeb 6, 2008
  27. Junio C HamanoFeb 6, 2008
  28. Junio C HamanoFeb 6, 2008
  29. Junio C HamanoFeb 6, 2008
  30. Junio C HamanoFeb 5, 2008
  31. Linus TorvaldsFeb 6, 2008
  32. Junio C HamanoFeb 6, 2008
  33. Karl HasselströmFeb 6, 2008
  34. Linus TorvaldsFeb 6, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.