summaryrefslogtreecommitdiff
path: root/diff.c
diff options
context:
space:
mode:
authorElijah Newren <newren@gmail.com>2017-11-13 20:15:59 (GMT)
committerJunio C Hamano <gitster@pobox.com>2017-11-15 04:11:25 (GMT)
commit9f7e4bfa3b6da16e3690312ff208cc27706b2c1b (patch)
treee53276ecfc9264ba8d57588291939e759c38b8ca /diff.c
parentd6861d0258df95987696eab6c9bbc138a07190b9 (diff)
downloadgit-9f7e4bfa3b6da16e3690312ff208cc27706b2c1b.zip
git-9f7e4bfa3b6da16e3690312ff208cc27706b2c1b.tar.gz
git-9f7e4bfa3b6da16e3690312ff208cc27706b2c1b.tar.bz2
diff: remove silent clamp of renameLimit
In commit 0024a5492 (Fix the rename detection limit checking; 2007-09-14), the renameLimit was clamped to 32767. This appears to have been to simply avoid integer overflow in the following computation: num_create * num_src <= rename_limit * rename_limit although it also could be viewed as a hardcoded bound on the amount of CPU time we're willing to allow users to tell git to spend on handling renames. An upper bound may make sense, but unfortunately this upper bound was neither communicated to the users, nor documented anywhere. Although large limits can make things slow, we have users who would be ecstatic to have a small five file change be correctly cherry picked even if they have to manually specify a large limit and wait ten minutes for the renames to be detected. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'diff.c')
-rw-r--r--diff.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/diff.c b/diff.c
index 0763e89..4005407 100644
--- a/diff.c
+++ b/diff.c
@@ -5454,7 +5454,7 @@ void diff_warn_rename_limit(const char *varname, int needed, int degraded_cc)
warning(_(rename_limit_warning));
else
return;
- if (0 < needed && needed < 32767)
+ if (0 < needed)
warning(_(rename_limit_advice), varname, needed);
}