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,这意味着我在其他目录中进行了更改,只是将它们复制粘贴到我的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

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 知道您重命名文件的完美方法。

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

然后 git 将接受这些更改。

享受。

Answer 4

而不是git status尝试git commit --dry-run -a,它会更好地检测重命名.

Answer 5

我刚刚遇到了类似的问题，在我的情况下，重命名被另一次提交更改，并且尝试将其重新更改为另一个提交在我的 Windows 版 Git 上失败，直到我意识到有一个相应的 git 配置。在我的系统中，git config将一种配置列为core.ignorecase=true.

通过将其设置回 false 来禁用git config core.ignorecase false它对我来说很有效。值得快速检查并尝试看看这是否导致 git 中的案例检测失败。这已经在 git 版本 2.33.0.windows.2 上尝试过。

Answer 6

最简单的方法就是简单地设置

git config core.ignorecase false

然后重做添加和提交。

如果您已经更改了大量文件名并且不想git mv手动执行此操作，那么这尤其有用。

true如果由于某种原因您不想默认尊重大写，您可以随时覆盖。

Answer 7

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

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