Re: What's in git.git

From: Linus Torvalds <torvalds@osdl.org>
Date: Mar 5, 2006, 04:58 UTC
Message-ID: <Pine.LNX.4.64.0603042058250.13139@g5.osdl.org>
In-Reply-To: <7vacc5jza6.fsf@assigned-by-dhcp.cox.net>

On Sat, 4 Mar 2006, Junio C Hamano wrote:

Show 8 quoted lines

> 
> 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--;
 	}