git merge ignores deleted files, existing on merged branch (renamed files)
I’ve got the branches feature1 and master.
Then in feature1 I renamed a file dir/file.txt into dir2/file2.txt.
After that I altered the file in master and a week later altered the file in feature1 too.
I have 40 files changed like that across the project.
When I try to merge master into feature1 I’m using low renaming threshold.
Most of the files are auto-merged correctly. Some files are offered for manual conflict resolution.
But some concrete files neither appear in the merge response as auto-merged,
nor getting merged properly. Under properly I expect one of two outcomes I could resolve:
1. It wouldnt detect renaming and just add me another dir/file.txt into the feature1 branch.
2. It would detect renaming and offer me to manually resolve conflict.
There are many changes when I view them with
git difftool master:dir/file.txt feature1:dir2/file2.txt
Therefore I assume that git recognizes the renaming and decides to keep my version
without informing me about what’s going on.
How can I solve it / 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 feature1 branch, I had deleted dir/file.txt.
Maybe git assumes this file should be deleted and therefore ignores it’s existence in master.
Renaming detection fails, although the similarity of the files is kept ( levenshtein distance is less than 2% of the content’s length )
Another discussion suggests ‘manual merge’ copying files from branch to branch.
Upd2
Some other files are resolved correctly
CONFLICT (rename/delete): images/ab.gif deleted in master and renamed in HEAD. Version HEAD of cdn/img/ab.gif left in tree.
Files that were removed in master and merged into feature1 are resolved correctly. Files that are deleted (or moved) in feature1 ain’t recognized at the merge.
Sugestions?
Upd3
At the moment I’m trying to merge the other way around. Merge feature1 into master and see what files
are being added and removed. This way I’ll a list of files git fail’s to recognize as renames and resort to manual merging.
2 Solutions collect form web for “git merge ignores deleted files, existing on merged branch (renamed files)”
If you are deleting files from your repo – git is tracking this deletion and the merge is considering this when determining what to do.
This is probably not all that you have going on, but it is part of it. You can try git add’ing them again.
Therefore I assume that git recognizes the renaming and decides to keep my version without informing me about what’s going on.
Git 2.13 (Q2 2017) will actually tell you more about what is going on:
When “
git merge” detects a path that is renamed in one history while the other history deleted (or modified) it, it now reports both paths to help the user understand what is going on in the two histories being merged.
See commit b26d87f (28 Jan 2017) by Matt McCutchen (mattmccutchen).
(Merged by Junio C Hamano — gitster — in commit 74aabf4, 27 Feb 2017)
merge-recursive: make “CONFLICT (rename/delete)” message show both paths
The current message printed by “
git merge-recursive” for a rename/delete
conflict is like 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 helpful, the message should show both paths of the rename and
state that the deletion occurred at the old path, not 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 (modify vs.
rename), refactor the code to halve the number of cases again by merging the
cases where o->branch1 has the change and o->branch2 has the delete with the
cases that are the other way around.