Thread (3 messages) flat view 3 messages, 3 authors, 2016-06-15

Re: What's in git.git

From: Linus Torvalds <torvalds@osdl.org>
Date: 2016-06-15 22:42:21
Subsystem: the rest · Maintainer: Linus Torvalds

On Sat, 4 Mar 2006, Junio C Hamano wrote:
The most notable core-ish change is that rev-list split and new
git-log implementation by Linus.  I've been using this myself
for a while without problems, but there might still be some
corner cases that I (and Linus perhaps) do not exercise where
git-log command behaves slightly differently.  rev-list is not
supposed to have *any* regression other than removal of
--merge-order.  Please report regressions.
Here's a potential fix for a special case that we used to have to make

	git-rev-list --max-count=1

be faster and not unnecessarily parse any parent objects.

Now, we had that special case because gitweb was apparently doing a lot of 
it, and quite frankly, I don't know if it still does. But basically it 
avoids doing the "pop_most_recent_commit()" which will look up and parse 
the parents, if it is obvious that it can.

I'm not sure this is worth it, but it looks obvious enough. Somebody with 
gitweb somewhere should probably check if it still even wants this.

		Linus

----
diff --git a/revision.c b/revision.c
index a3df810..33a5f20 100644
--- a/revision.c
+++ b/revision.c
@@ -696,6 +696,18 @@ struct commit *get_revision(struct rev_i
 		break;
 	case 0:
 		return NULL;
+
+	/* Special case to avoid unnecessary parent checking */
+	case 1:
+		if (!revs->limited &&
+		    !revs->no_merges &&
+		    !revs->paths &&
+		    revs->min_age == -1 &&
+		    revs->max_age == -1) {
+		    	revs->max_count = 0;
+			commit->object.flags |= SHOWN;
+			return commit;
+		}
 	default:
 		revs->max_count--;
 	}
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help