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之外进行的。我做了以下事情：

创建了refactoringBranch来自master。
删除了refactoringBranch中更改的结构，这意味着我在其他目录中进行了更改，只是将它们复制粘贴到我的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步骤上。因为如果重命名检测在那里是正确的，我会假设合并将完美无缺。

Answer 1

OS X是区分大小写的，但不敏感。 Git 区分大小写。如果您更改了文件名，并且唯一的更改是大小写更改，请将文件重命名为原来的版本，然后使用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 status，而不是git commit --dry-run -a，它会更好地检测重命名。

Answer 4

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

根据我的经验，它更加可靠。

Answer 5

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

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

然后git将获取这些更改。

享受。

Answer 6

每当我不得不重命名/移动文件并忘记明确告诉GIT时我使用了

git add . -A

自动检测移动的文件

git无法检测到重命名

史前

6 个答案: