the documentation does not mention 0 as a special value for diff.renamelimit .
Therefore, you should set this limit to the recommended value.
Or you can try to deactivate rename detection altogether. ( git config diff.renames 0 )
You will find a similar example on this blog: Confluence, git, rename, merge oh my ... ":
As already mentioned, git tries to detect file renaming after this fact, for example when using git log or git diff/merge .
When trying to detect renames, git distinguishes between the exact and inaccurate renaming names, the first of which is renaming without changing the contents of the file, and the second is renaming, which may include changes to the contents of the file (for example, renaming / moving a Java class).
This difference is important because the algorithm for detecting exact renames is linear and will always be executed if the algorithm for determining an inaccurate rename name is quadratic ( O(n^2) ) and git does not try to do this if the number of modified files exceeds a certain threshold (by default 1000 )
Since the number of files affected by the recent reorganization exceeds this threshold, git simply drops and leaves the merge permission to the developer. In our case, we can avoid manually allowing the merge, although by changing the threshold
Note: git 2.16 (Q1 2018) will change this limit:
Historically, the differentiation mechanism for detecting renaming had a hard-coded limit of 32k paths; this is removed so that users of trading cycles with a (possibly) easier to read result.
See commit 8997355 (November 29, 2017) by Jonathan Tan ( jhowtan ) .
See commit 9268cf4 , commit 9f7e4bf , commit d6861d0 , commit b520abf (November 13, 2017) Elijah Newren ( newren ) .
(merged Junio C Hamano - gitster - in commit 6466854 , December 19, 2017
diff : remove silent clip renameLimit
In commit 0024a54 (Correct rename restriction check, September 2007, git v1.5.3.2), renameLimit was clamped to 32767.
Apparently, this was just to avoid integer overflow in the following calculation:
num_create * num_src <= rename_limit * rename_limit
Although it can also be considered as strictly tied to the amount of CPU, the time we are willing to allow users to tell git to spend on processing renames.
The upper bound may make sense, but, unfortunately, this upper bound is not shared with anyone and is not documented anywhere.
Although large restrictions can slow down, we have users who will be ecstatic to have a small five file changes, the cherry is selected correctly even if they need to manually specify a large limit and wait ten minutes for the renaming to be detected.
Existing scripts and tools that use " -l0 " continue to work, treating 0 as a special value, indicating that the renaming limit should be very large.