Warning on “diff.renamelimit variable” when doing git push

Question

I\'m pushing the local commit to the remote git server and got the following warning messages:

remote: warning: only found copies from modified paths due to too          


        

Answer 1

The documentation doesn't mention 0 as a special value for diff.renamelimit.
So you should set that limit to the value recommended.
Or you can try deactivating the rename detection altogether. (git config diff.renames 0)

You will find a similar example in this blog post "Confluence, git, rename, merge oh my...":

As already mentioned, git tries to detect file renames after that fact, for example when using git log or git diff/merge.
When trying to detect renames git distinguishes between exact and inexact renames with the former being a rename without changing the content of the file and the latter a rename that might include changes to the content of the file (e.g. renaming/moving a Java Class).
This distinction is important because the algorithm for detecting exact renames is linear and will always be executed while the algorithm for inexact rename detection is quadratic ( O(n^2) ) and git does not attempt to do this if the number of files changed exceeds a certain threshold (1000 by default).

As the number of files affected by the recent reorganisation exceeds this threshold, git simply gives up and leaves the merge resolution up to the developer. In our case we can avoid doing manual merge resolution though by changing the threshold

---

Note: Git 2.16 (Q1 2018) will amend that limit:

Historically, the diff machinery for rename detection had a hardcoded limit of 32k paths; this is being lifted to allow users trade cycles with a (possibly) easier to read result.

See commit 8997355 (29 Nov 2017) by Jonathan Tan (jhowtan).
See commit 9268cf4, commit 9f7e4bf, commit d6861d0, commit b520abf (13 Nov 2017) by Elijah Newren (newren).
^{(Merged by Junio C Hamano -- gitster -- in commit 6466854, 19 Dec 2017)}

diff: remove silent clamp of renameLimit

In commit 0024a54 (Fix the rename detection limit checking; Sept. 2007, Git v1.5.3.2), 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 hard-coded 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.

Existing scripts and tools that use "-l0" to continue working, treating 0 as a special value indicating that the rename limit is to be a very large number.

---

Git 2.17 (Q2 2018) will avoid showing a warning message in the middle of a line of "git diff" output.

See commit 4e056c9 (16 Jan 2018) by Nguyễn Thái Ngọc Duy (pclouds).
^{(Merged by Junio C Hamano -- gitster -- in commit 17c8e0b, 13 Feb 2018)}

diff.c: flush stdout before printing rename warnings

The diff output is buffered in a FILE object and could still be partially buffered when we print these warnings (directly to fd 2).
The output is messed up like this

 worktree.c                                   |   138 +-
 worktree.h        warning: inexact rename detection was skipped due to too many files.
                           |    12 +-
 wrapper.c                                    |    83 +-

It gets worse if the warning is printed after color codes for the graph part are already printed. You'll get a warning in green or red.

Flush stdout first, so we can get something like this instead:

 xdiff/xutils.c                               |    42 +-
 xdiff/xutils.h                               |     4 +-
 1033 files changed, 150824 insertions(+), 69395 deletions(-)
warning: inexact rename detection was skipped due to too many files.