Git merge ignores deleted files existing in the merged branch (renamed files)

Question

I have feature1 and master branches.
Then in feature1 I renamed dir/file.txt to dir2/file2.txt .
After that, I changed the file in master , and a week later changed the file in feature1 too.

I have 40 files modified this way in a project.
When I try to combine master in feature1 , I use a low renaming threshold. Most files are automatically grouped. Some files are offered to resolve conflicts manually.

But some specific files do not appear in the merge response as automatically merging,
and do not merge properly . In due course, I expect one of two results that I could solve:
1. It will not detect the renaming and just add me dir/file.txt to the feature1 branch.
2. He will detect the renaming and offer me to manually resolve the conflict.

There are many changes when I view them using git difftool master:dir/file.txt feature1:dir2/file2.txt

Therefore, I assume that git recognizes the renaming and decides to save my version without telling me what is going on. How can I solve / debug it?

This is the command I use

 git config merge.renameLimit 9999999999 git merge --no-ff -Xrename-threshold=20 -Xignore-space-change master 

Upd1

While working with the feature1 branch feature1 I deleted dir/file.txt .
Perhaps git suggests that this file should be deleted and therefore ignores its existence in master .
Rename detection fails, although file similarity is preserved (levenshtein distance is less than 2% of the content length)
Another discussion suggests "manual merge" to copy files from branch to branch.

UPD2

Some other files are correctly resolved.
CONFLICT (rename/delete): images/ab.gif deleted in master and renamed in HEAD. Version HEAD of cdn/img/ab.gif left in tree.
Files deleted in master and merged in feature1 correctly. Files deleted (or moved) in feature1 are not recognized when merging.
Sugestions?

Upd3

I'm trying to unite at the moment. Drain feature1 into master and see which files are added and deleted. Thus, the list of git files will not be recognized as renaming and resort to manual merging.

Answer 1

If you delete files from your repo - git tracks this deletion, and merge considers this when deciding what to do.

This is probably not all that happens to you, but it is part of it. You can try git add them again.

Answer 2

Therefore, I assume that git recognizes the renaming and decides to save my version without telling me what is going on.

Git 2.13 (Q2 2017) will actually tell you more about what's going on:

When " git merge " detects a path that has been renamed in one story while another story is deleted (or changed), it now reports both paths to help the user understand what is happening in the two stories merging .

See commit b26d87f (January 28, 2017) by Matt McCutchen .
^{(merger of Junio ​​C Hamano - gitster - at commit 74aabf4 , February 27, 2017)}

merge-recursive: make the message "CONFLICT (rename / delete)" show both ways

The current message printed by " git merge-recursive " to rename / delete the conflict is this:

 CONFLICT (rename/delete): new-path deleted in HEAD and renamed in other-branch. Version other-branch of new-path left in tree. 

To be more useful, the message should show both renaming paths and indicate that the deletion occurred on the old path, and not on the new path. So change the message to the following format:

 CONFLICT (rename/delete): old-path deleted in HEAD and renamed to new-path in other-branch. Version other-branch of new-path left in tree. 

Since this doubles the number of cases in handle_change_delete (change vs. rename), reorganize the code to halve the number of cases by combining cases where o-> branch1 has the change and o-> branch2 has the deletion using cases that are in the opposite direction.