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. 创建了源自master 的refactoringBranch。
2. 在refactoringBranch 中删除了更改的结构，这意味着我在其他一些目录中进行了更改，然后将它们复制粘贴到我的git 存储库中。
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

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

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

然后 git 会接受这些更改。

享受吧。

Answer 2

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

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

Answer 3

OS X 可以区分大小写，但不敏感。 Git ​​ 区分大小写。如果您更改了文件名并且唯一的更改是大小写更改，请将文件重命名为原来的名称，然后改用 git mv 重命名。

Answer 4

代替git status，尝试git commit --dry-run -a，它可以更好地检测重命名。

Answer 5

重命名检测：

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

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

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

合并：

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

Answer 6

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

git add . -A

自动检测移动的文件