git - git 无法检测到重命名

Question

一个分支 ( refactoringBranch) 进行了完整的目录重组。文件被乱动，但内容被保留了下来。

我试图合并： git merge --no-ff -Xrename-threshold=15 -Xpatience -Xignore-space-change refactoringBranch

git status 显示大约一半的文件重命名识别。但在项目中的 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 之外进行的。我做了以下事情：

1. 创建了refactoringBranch起源于master.
2. 将更改后的结构refactoringBranch放到 .
3. 添加并提交所有内容，然后尝试合并。

这是我的工作流程：

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步骤上。因为如果那里的重命名检测是正确的，我会假设合并会完美无缺。

Answer 1

OS X 区分大小写，但不敏感。Git ​<em>​区分大小写。如果您更改了文件名并且唯一的更改是大小写更改，请将文件重命名回原来的方式，然后使用git mv重命名。

Answer 2

重命名检测：

我最好的猜测是，由于候选人数量众多，重命名检测失败了。git 源代码在某些地方有点难以理解，但似乎在重命名检测算法的特定搜索步骤中使用了一些硬编码限制（请参阅 参考资料diffcore-rename.c），以及对最大数量的可配置限制要查看的对（配置键diff.renameLimit和merge.renameLimit）。即使您已将配置的限制设置得适当高，这也可能导致检测失败。可配置限制本身被限制在 [1, 32767] 范围内。

也许您可以通过首先执行重组步骤来解决此问题：使用 git mv 移动文件而不进行任何内容更改，以匹配新布局，将其提交到新分支上，然后用您的最终版本替换它，它应该只有内容更改，没有重命名。可能更可靠地检测到没有内容更改的重命名。这只有在您所做的重组相当简单的情况下才实用，而且我不确定它是否会解决重命名检测失败。

或者，也许您可​​以使用一些简单的文件分组将更改拆分为单独的提交，以便在每个提交中进行重命名检测的候选者更少。

合并：

不幸的是，通过将新分支建立在 master 之上，您向 git 提供了有关合并的错误信息。无论是否正确检测到重命名，当新创建的分支与 master 合并时，它将覆盖 master 中的所有内容，因为从 git 的角度来看，master 中没有尚未包含在新分支中的更改.

Answer 3

这是让 git 知道您重命名文件的完美方法。

git mv old-file-name.ts new-file-name.ts

然后 git 将获取这些更改。

享受。

Answer 4

而不是git status, try git commit --dry-run -a，它可以更好地检测重命名。

Answer 5

您可以考虑git mv改用：https ://www.kernel.org/pub/software/scm/git/docs/git-mv.html

根据我的经验，它要可靠得多。

Answer 6

每当我不得不重命名/移动文件而忘记明确告诉 GIT 时，我都会使用

git add . -A

自动检测移动的文件