git fails to detect renaming

One branch (refactoringBranch) had a complete directory restructure. Files were moved chaosly, but the content was preserved.

I tried to merge: git merge --no-ff -Xrename-threshold=15 -Xpatience -Xignore-space-change refactoringBranch

git status shows about half of files renaming recognition. But out of 10000 files in the project half wasn't recognized as moved.

One example would be:

# On branch master
# Changes to be committed:

#	deleted:    404.php
#	new file:   public_html/404.php
	...
#	deleted:    AnotherFile.php
#	new file:   public_html/AnotherFile.php
	...
#	renamed:    contracts/css/view.css -> public_html/contracts/css/view.css

Suggestions?

---

Prehistory

The refactoring was made outside of git. I did the following:

1. Created the refactoringBranch originating on master.
2. Dropped the changed structure inside the refactoringBranch, meaning I had my changes in some other dir and just copy-pasted them over my git repository.
3. Added and committed everything and then tried to merge.

This is was my workflow:

git checkout -b refactoringBranch
cp -R other/place/* ./
git add . -A
git commit -a -m "blabla"
git checkout master
git merge --no-ff -Xrename-threshold=15 -Xpatience -Xignore-space-change refactoringBranch

The problem arise on the git add . -A step probably. Because if rename detection was correct there, I'd assume the merge would go flawless.

OS X is case-aware, but not sensitive. Git ​_is_​ case-sensitive. If you changed a file name and the only change was a case change, rename the file back to the way it was, then use git mv to rename instead.

Rename detection:

My best guess is that rename detection is failing due to the very large number of candidates. The git source code is a little hard to follow in places, but it does appear that there are some hard-coded limits used in particular search steps of the rename detection algorithm (see diffcore-rename.c), as well as the configurable limit on the maximum number of pairs to look at (configuration keys diff.renameLimit and merge.renameLimit). This may be making detection fail even if you have set the configured limit suitably high. The configurable limit itself is clamped to the range [1, 32767].

Perhaps you can get around this by performing a restructuring step first: move files with git mv without making any content changes, to match the new layout, commit that on a new branch, and then replace it with your final version, which should have only content changes and no renames. Renames with no content changes might be detected more reliably. That's only practical if the restructuring you've done has been fairly simple, and I'm not certain that it will solve the rename detection failures.

Alternatively, perhaps you can split the changes up into separate commits with some simple file groupings, so that there are fewer candidates for rename detection in each commit.

Merging:

Unfortunately, by basing the new branch on top of master, you are giving git incorrect information about the merge. Independent of whether renames are correctly detected or not, when the newly created branch is merged with master it will overwrite everything in master, because from git's point of view, there are no changes in master that haven't already been included in the new branch.

Here is a perfect way to allow git know you rename a file.

git mv old-file-name.ts new-file-name.ts

Then git will pick up those changes.

Enjoy.

Instead of git status, try git commit --dry-run -a, it detects renames better.

You could consider using git mv instead: https://www.kernel.org/pub/software/scm/git/docs/git-mv.html

It has been much more reliable in my experience.

Whenever I had to rename/move files and forgot to tell GIT explicitly about it I used

git add . -A

which auto-detects files that were moved around