19

Let's say I have a file that's

  1. Modified in master
  2. Modified in a feature branch
  3. Renamed in a feature branch

When I try to merge up from master to the feature branch, merge fails with

CONFLICT (modify/delete): X deleted in HEAD and modified in origin/master. Version origin/master of X left in tree.

I understand that there is a conflict, but why doesn't it even try to merge changes and place conflict markers in the file? Previous answers seem to imply that it should. All I get is two different versions of the file, where I have to figure out the difference manually and port changes line by line from master version to my version.

Steps to reproduce:

git init
touch a
git add a
git commit -m 'initial import'

git checkout -b feature1
echo feature1 > a
git add a
git commit -m feature1
git mv a b
git commit -m feature1

git checkout master
echo bugfix > a
git add a
git commit -m bugfix

git checkout feature1 
git merge master
Community
  • 1
  • 1
Alex B
  • 82,554
  • 44
  • 203
  • 280

1 Answers1

32

Because there is actually no concept of first-class rename operation in git, it just "detects" renames using a threshold for file differences. Your files are probably too different.

Try merging with: git merge master -s recursive -X rename-threshold=5%

akent
  • 4,068
  • 28
  • 27
  • When you initially commit a rename, there appears to already be a threshold being used since the renamed file can contain minor differences. Any idea why it wouldn't just use the same threshold? I would expect since it picked up on the rename on the initial commit, it should maintain this on a merge or rebase. – Sean Adkinson Nov 20 '13 at 15:55
  • 1
    @SeanAdkinson Because the default merging strategy merges only the final results, not each commit. So if the file was changed in another commit after the rename it may no longer meet the threshold, even if it did before. – gcscaglia Apr 30 '16 at 14:21
  • Note that the `%` in `rename-threshold` is crucial. – Mike Caron Jul 22 '16 at 19:39