Git doesn't detect rename when file has been modified significantly after move

Question

Consider this test script.

#!/bin/sh -x
rm -rf test
git init test
cd test
for I in {1..100}; do
    echo $I >> x
done
git add x
git commit -am "initial commit"
git checkout -b branch
git mv x y
git commit -am "renamed"
rm y
for I in {1..60}; do
    echo branch$I >> y
done
for I in {61..100}; do
    echo $I >> y
done
git commit -am "changed the first 60 lines in branch"
git checkout master
rm x
for I in {1..60}; do
    echo master$I >> x
done
for I in {61..100}; do
    echo $I >> x
done
git commit -am "changed the first 60 lines in master"
git merge -s recursive -X patience branch
git status

What I want to happen is for git to detect that x was renamed to y in the branch, and give me the opportunity to resolve the merge conflict.

Instead what happens is git ignores (fails to detect) the rename, and says that x was deleted in the branch while a new unrelated file y was created. How can I convince git to handle this as a renamed file?

Thank you!

Answer 1

You are correct: git does rename-detection, rather than rename-tracking, and if the file has changed "too much" (for some value of "too much"), git declares this to be a different file, rather than a renamed file.

There is no perfect fix for this. Often the best option, if your git is new enough (1.7.4 or later), is to pass the -X rename-threshold=<n> flag to git merge. Lowering the threshold makes git detect more renames (and you can use git diff -M to test for an appropriate threshold value).