git无法检测重命名。
一个分支(refactoringBranch)有一个完整的目录重组。文件被混沌地移动，但内容被保存下来。
我试图合并：git merge --no-ff -Xrename-threshold=15 -Xpatience -Xignore-space-change refactoringBranch
git状态显示了大约一半的文件重命名识别。但是，在项目中的10000个文件中，有一半没有被识别为已移动。
一个例子是：
# On branch master
# Changes to be committed:
# deleted: 404.php
# new file: public_html/404.php
...
# deleted: AnotherFile.php
# new file: public_html/AnotherFile.php
...
# renamed: contracts/css/view.css -> public_html/contracts/css/view.css有什么建议吗？
史前
重构是在git之外进行的。我做了以下工作：
- 创建了起源于
refactoringBranch的master。 - 在
refactoringBranch中删除了更改的结构，这意味着我在其他dir中进行了更改，并将它们复制粘贴到我的git存储库中。 - 添加并提交所有内容，然后尝试合并。
这是我的工作流程：
git checkout -b refactoringBranch
cp -R other/place/* ./
git add . -A
git commit -a -m "blabla"
git checkout master
git merge --no-ff -Xrename-threshold=15 -Xpatience -Xignore-space-change refactoringBranch这个问题可能出现在git add . -A步骤中。因为如果重命名检测是正确的，我认为合并会完美无缺。
Stack Overflow用户
发布于 2012-12-10 20:30:56
重命名检测：
我最好的猜测是，重命名检测失败是由于大量的候选人。git源代码在某些地方有点难以理解，但似乎在重命名检测算法(参见diffcore-rename.c)的特定搜索步骤中使用了一些硬编码限制，以及对要查看的最大对数(配置键diff.renameLimit和merge.renameLimit)的可配置限制。这可能会导致检测失败，即使您已经将配置的限制设置得适当高。可配置限制本身被夹紧到范围1,32767。
也许您可以先执行重组步骤:使用git mv移动文件而不进行任何内容更改，以匹配新布局，将其提交到新分支上，然后将其替换为您的最终版本，该版本应该只有内容更改而没有重命名。可以更可靠地检测到没有内容更改的重命名。只有在您所做的重组相当简单的情况下，这才是实际的，而且我不确定它是否会解决重命名检测失败。
或者，您也可以通过一些简单的文件分组将更改拆分为单独的提交，以便在每个提交中有更少的候选重命名检测。
合并：
不幸的是，通过将新的分支建立在master的基础上，您提供了关于合并的git错误信息。无论重命名是否被正确检测到，当新创建的分支与master合并时，它将覆盖主服务器中的所有内容，因为从git的角度来看，新分支中没有包含的主程序中没有任何更改。
https://stackoverflow.com/questions/13805750
复制相似问题
腾讯云开发者
