Git does not detect renaming when a file has been significantly modified after moving

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 xy 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 

I want this to happen, so that git detects that x been renamed to y in the branch, and give me the opportunity to resolve the merge conflict.

Instead, the following happens: git ignores (does not detect) the renaming and says that x was deleted in the branch while a new unrelated file y was created. How can I convince git to treat this as a renamed file?

Thanks!

Answer 1

You are right: git does the renaming, not the renaming-tracking, and if the file has changed “too much” (for some value “too much”), git declares that it is a different file, not a renamed file.

There is no perfect solution for this. Often the best option if your git is fairly new (1.7.4 or newer) should 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 check the corresponding threshold).