summaryrefslogtreecommitdiff
path: root/debian/changelog
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@osdl.org>2005-08-10 23:26:32 (GMT)
committerJunio C Hamano <junkio@cox.net>2005-08-12 01:26:12 (GMT)
commit0b9442d618bedd5bef7ec4ef5829b82df57e89eb (patch)
tree765f2585e8b9def58562331d6003b71f82557825 /debian/changelog
parent2b64f88f09ae2169ec85652b46897574e352936d (diff)
downloadgit-0b9442d618bedd5bef7ec4ef5829b82df57e89eb.zip
git-0b9442d618bedd5bef7ec4ef5829b82df57e89eb.tar.gz
git-0b9442d618bedd5bef7ec4ef5829b82df57e89eb.tar.bz2
[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>
Diffstat (limited to 'debian/changelog')
0 files changed, 0 insertions, 0 deletions