[PATCH] Speed up git-merge-base a lot
authorLinus Torvalds <torvalds@osdl.org>
Wed, 10 Aug 2005 23:26:32 +0000 (16:26 -0700)
committerJunio C Hamano <junkio@cox.net>
Fri, 12 Aug 2005 01:26:12 +0000 (18:26 -0700)
commit0b9442d618bedd5bef7ec4ef5829b82df57e89eb
tree765f2585e8b9def58562331d6003b71f82557825
parent2b64f88f09ae2169ec85652b46897574e352936d
[PATCH] Speed up git-merge-base a lot

In commit 4f7eb2e5a351e0d1f19fd4eab7e92834cc4528c2 I fixed git-merge-base
getting confused by datestamps that caused it to traverse things in a
non-obvious order.

However, my fix was a very brute-force one, and it had some really
horrible implications for more complex trees with lots of parallell
development. It might end up traversing all the way to the root commit.

Now, normally that isn't that horrible: it's used mainly for merging, and
the bad cases really tend to happen fairly rarely, so if it takes a few
seconds, we're not in too bad shape.

However, gitk will also do the git-merge-base for every merge it shows,
because it basically re-does the trivial merge in order to show the
"interesting" parts. And there we'd really like the result to be
instantaneous.

This patch does that by walking the tree more completely, and using the
same heuristic as git-rev-list to decide "ok, the rest is uninteresting".

In one - hopefully fairly extreme - case, it made a git-merge-base go from
just under five seconds(!) to a tenth of a second on my machine.

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