7

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.

Community
  • 1
  • 1
Alex
  • 11,479
  • 6
  • 28
  • 50
  • have you tried rebasing feature1 on top of master, instead of merging master into feature1? – Steve Goodman Oct 22 '12 at 15:20
  • I did. Got the same effect but with different files being 'forgotten'. I ended up manually merging those few files that were deleted and renamed. – Alex Oct 22 '12 at 15:25
  • That's interesting; this seems like exactly the type of situation rebase would handle well. You might try messing with merge strategies, but I'm not sure about the root of your issue. http://www.kernel.org/pub/software/scm/git/docs/git-merge.html (Merge strategies section) – Steve Goodman Oct 22 '12 at 15:29
  • Perhaps the resolution here will help:: http://stackoverflow.com/questions/4722423/how-to-merge-two-branches-with-different-directory-hierarchies-in-git – Thell Oct 22 '12 at 15:42
  • 1
    How are you deleting the files under version control? git rm will help manage these things and do the right thing. If it is a move, then git mv will do the right thing. Of course, you still need to stage them. Concerning your third update, don't forget that you are allowed to checkout files directly from other branches or repositories. This may assist in your recovering those files. – vgoff Nov 02 '12 at 23:58
  • Do all the files have a common ancestry? I also would like to know if you are using git rm and git mv? – Michael Nov 09 '12 at 02:33

2 Answers2

1

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.

Michael
  • 10,124
  • 1
  • 34
  • 49
  • That turned out to be the problem. As noted in upd1, I had some files deleted in my `feature1` branch and whet `master` was merged in, git recognized it was the same file and thus skipped it ( as it thought this file should not appear in the `feature1` branch at all. – Alex Nov 15 '12 at 08:28
0

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.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250