5

This question came to me after reading this one : Can Git really track the movement of a single function from 1 file to another? If so, how?

Here is the worfklow :

A "long time ago", we splitted a big file folder/file.py in many files : folder1/file.py, folder2/file.py and so on.

git blame -C shows correctly the history of that code when we look at folder2/file.py, we see that some of the commits were made before this splitting.

The problem is that we continue to maintain old versions of the code that still have folder/file.py and when we merge the fixes back in the "current" version, git keeps re-creating the folder folder and does not see that a fix made to folder/file.py should be merged into folder1/file.py OR folder2/file.py depending on where this chunk of code is now located.

I look rapidly at git help merge but did not find anything about that.

Community
  • 1
  • 1
Ghislain Leveque
  • 958
  • 1
  • 8
  • 21
  • does this help? http://stackoverflow.com/questions/11005813/git-putting-folders-in-folders-in-a-repository/11010454#11010454 – uday Jun 15 '12 at 09:07

1 Answers1

0

Merges cannot leverage git blame -C, but git merge does have rename detection. From the man page:

   rename-threshold=<n>
   Controls the similarity threshold used for rename detection. See also git-diff(1) -M.

Git's rename threshold is likely too high to detect your renames during merge. It's also possible the detection is too computationally intense. Try conducting a test merge with a lower rename-threshold, say 75:

git merge -X rename-threshold=75 <branch>

You might have to play around for a while to find the right number, and if git quits because it's too computationally difficult, try setting the git config merge.renamelimit 0 discussed in the thread linked above.

This answer might also help if the above fails. I haven't tried -X ignore-space-change or the linked script, but it might be worth investigation.

Community
  • 1
  • 1
Christopher
  • 42,720
  • 11
  • 81
  • 99