author | Linus Torvalds <torvalds@osdl.org> | |
Wed, 10 Aug 2005 23:26:32 +0000 (16:26 -0700) | ||
committer | Junio C Hamano <junkio@cox.net> | |
Fri, 12 Aug 2005 01:26:12 +0000 (18:26 -0700) | ||
commit | 0b9442d618bedd5bef7ec4ef5829b82df57e89eb | |
tree | 765f2585e8b9def58562331d6003b71f82557825 | tree | snapshot |
parent | 2b64f88f09ae2169ec85652b46897574e352936d | commit | diff |
[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>
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 | diff | blob | history |