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--;
}
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html