author | Jeff King <peff@peff.net> | |
Sat, 19 Feb 2011 10:21:28 +0000 (05:21 -0500) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Mon, 21 Feb 2011 18:23:36 +0000 (10:23 -0800) | ||
commit | 92c57e5c1d29db96a927e2a713c5aa4ae99ce749 | |
tree | 044abd7e328d2b19d7a40931197d3f582ae8bb3a | tree | snapshot |
parent | bf0ab10fa84df6c49450a06077d1c52756d88222 | commit | diff |
bump rename limit defaults (again)
We did this once before in 5070591 (bump rename limit
defaults, 2008-04-30). Back then, we were shooting for about
1 second for a diff/log calculation, and 5 seconds for a
merge.
There are a few new things to consider, though:
1. Average processors are faster now.
2. We've seen on the mailing list some ugly merges where
not using inexact rename detection leads to many more
conflicts. Merges of this size take a long time
anyway, so users are probably happy to spend a little
bit of time computing the renames.
Let's bump the diff/merge default limits from 200/500 to
400/1000. Those are 2 seconds and 10 seconds respectively on
my modern hardware.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We did this once before in 5070591 (bump rename limit
defaults, 2008-04-30). Back then, we were shooting for about
1 second for a diff/log calculation, and 5 seconds for a
merge.
There are a few new things to consider, though:
1. Average processors are faster now.
2. We've seen on the mailing list some ugly merges where
not using inexact rename detection leads to many more
conflicts. Merges of this size take a long time
anyway, so users are probably happy to spend a little
bit of time computing the renames.
Let's bump the diff/merge default limits from 200/500 to
400/1000. Those are 2 seconds and 10 seconds respectively on
my modern hardware.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff.c | diff | blob | history | |
merge-recursive.c | diff | blob | history |