在阅读完这篇文章之后，我想到了这个问题：Can Git really track the movement of a single function from 1 file to another? If so, how?
这是worfklow：
“很久以前”，我们在许多文件中分割了一个大文件folder/file.py：folder1/file.py，folder2/file.py等等。
git blame -C在我们查看folder2/file.py时正确显示了该代码的历史记录，我们看到有些提交是在此拆分之前完成的。
问题是我们继续维护仍然具有folder/file.py的旧版本代码，当我们在“当前”版本中合并修复时，git会不断重新创建文件夹folder并且没有看到对folder/file.py的修补程序应该合并到folder1/file.py OR folder2/file.py中，具体取决于此代码块的位置。
我快速查看git help merge，但没有发现任何相关信息。
答案 0 :(得分：0)
合并无法使用git blame -C，但git merge确实具有重命名检测功能。从手册页：
rename-threshold=<n>
Controls the similarity threshold used for rename detection. See also git-diff(1) -M.
Git的重命名阈值可能太高，无法在合并期间检测到您的重命名。 detection is too computationally intense.尝试使用较低的重命名阈值进行测试合并也是可能的，例如75：
git merge -X rename-threshold=75 <branch>
您可能需要玩一段时间才能找到正确的数字，如果git因为计算难度太大而退出，请尝试设置上面链接的线程中讨论的git config merge.renamelimit 0。
This answer might also help if the above fails.我没有尝试-X ignore-space-change或链接脚本，但可能值得调查。