GIT warning: too many files skipping inexact rename detection

Question

I am aware that the default rename limit is 100 and we can increase this value using the config diff.renamelimit config

What I am worried about is that, if this config is not setup, will there be a wrong merge or any missing code? I am trying to merge (git merge) 2 branches that have huge changes.

Can someone throw more light about this config setting?

I had the same experience, and I can confirm the message is simply a warning with no consequences other than a few pesky merge conflicts. — Johan H, Apr 29 '19 at 06:16

score 73 · Answer 1 · answered Mar 21 '18 at 09:53

73

In case this helps anyone, I had a lot of files (hundreds, if not thousands) in one branch, which were not yet in the other branch. Running

$ git config merge.renamelimit 15345

made the below error when merging go away

$ git merge master
.
.
.
warning: inexact rename detection was skipped due to too many files.
warning: you may want to set your merge.renamelimit variable to at least 15345 and retry the command.

answered Mar 21 '18 at 09:53

M3RS

6,720
6
37
47

3

Also, after setting the rename limit, before retrying merge, call "git merge --abort" to abort the current merge in progress. – robbie fan Sep 18 '21 at 06:55

score 73 · Accepted Answer · answered Mar 03 '11 at 13:53

73

Your content is safe.

As I understand it, git doesn't actually have any concept of a first-class rename operation (only bzr does, of the big 3 DVCSs): the mv is sugar on top of the underlying machinery, which is basically an add and a rm. Since git can track the content that changes during such operations, though, it can use heuristics to guess when an add and a rm are actually a mv. Since that takes way more work than just displaying what git actually recorded—the docs for git-diffexplain that it "...require O(n^2) processing time where n is the number of potential rename/copy targets"—git won't try it when too many files are involved. The setting you mention just controls that threshold.

answered Mar 03 '11 at 13:53

Hank Gay

70,339
36
160
222

33

"Your content is safe" - though if the detection misses a file which was renamed on one side of a merge and changed on the other, you'll get merge conflicts which you might not have gotten had the rename been detected. The merge won't be *wrong*, but it might require more user effort to complete. – Cascabel Mar 03 '11 at 17:53
2

Thanks Hank and Jefromi. Will setting up this "diff.renamelimit config" really be useful in any situations? – Senthil A Kumar Mar 04 '11 at 06:45
6

If someone is wondering too if this setting is useful: yes, it can help you merge branches when in one branch you have moved hundreds of files and in other you made a lot of changes in those files. I had situation like that when I had huge code refactor on one branch and some ongoing work on other. – korda Jan 08 '15 at 10:11

GIT warning: too many files skipping inexact rename detection

2 Answers2