Optimize common case of git-rev-list

I took a look at webgit, and it looks like at least for the "projects"
page, the most common operation ends up being basically

	git-rev-list --header --parents --max-count=1 HEAD

Now, the thing is, the way "git-rev-list" works, it always keeps on
popping the parents and parsing them in order to build the list of
parents, and it turns out that even though we just want a single commit,
git-rev-list will invariably look up _three_ generations of commits.

It will parse:
 - the commit we want (it obviously needs this)
 - it's parent(s) as part of the "pop_most_recent_commit()" logic
 - it will then pop one of the parents before it notices that it doesn't
   need any more
 - and as part of popping the parent, it will parse the grandparent (again
   due to "pop_most_recent_commit()".

Now, I've strace'd it, and it really is pretty efficient on the whole, but
if things aren't nicely cached, and with long-latency IO, doing those two
extra objects (at a minimum - if the parent is a merge it will be more) is
just wasted time, and potentially a lot of it.

So here's a quick special-case for the trivial case of "just one commit,
and no date-limits or other special rules".

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

diff --git a/rev-list.c b/rev-list.c
index c60aa72957cb65501266911aefd8aaaa2f2e4e16..3a32e405a38faebe0d4b7ec3b743fe3e15cfd3cf 100644 (file)
--- a/rev-list.c
+++ b/rev-list.c
@@ -624,6 +624,11 @@ int main(int argc, char **argv)
 
        if (!merge_order) {             
                sort_by_date(&list);
+               if (list && !limited && max_count == 1 &&
+                   !tag_objects && !tree_objects && !blob_objects) {
+                       show_commit(list->item);
+                       return 0;
+               }
                if (limited)
                        list = limit_list(list);
                if (topo_order)