git 无法检测到重命名

git fails to detect renaming

提问by Alex

One branch (refactoringBranch) had a complete directory restructure. Files were moved chaosly, but the content was preserved.

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

I tried to merge: git merge --no-ff -Xrename-threshold=15 -Xpatience -Xignore-space-change refactoringBranch

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

git status shows about half of files renaming recognition. But out of 10000 files in the project half wasn't recognized as moved.

git status 显示大约一半的文件重命名识别。但是项目中的 10000 个文件中有一半未被识别为已移动。

One example would be:

一个例子是：

# 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

Suggestions?

建议？

---

---

Prehistory

史前史

The refactoring was made outside of git. I did the following:

重构是在 git 之外进行的。我做了以下事情：

1. Created the refactoringBranchoriginating on master.
2. Dropped the changed structure inside the refactoringBranch, meaning I had my changes in some other dir and just copy-pasted them over my git repository.
3. Added and committed everything and then tried to merge.

1. 创建refactoringBranch起源于master.
2. 将更改后的结构放在 . 中refactoringBranch，这意味着我在其他目录中进行了更改，然后将它们复制粘贴到我的 git 存储库中。
3. 添加并提交所有内容，然后尝试合并。

This is was my workflow:

这是我的工作流程：

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

The problem arise on the git add . -Astep probably. Because if rename detection was correct there, I'd assume the merge would go flawless.

问题可能出现在git add . -A步骤上。因为如果重命名检测在那里是正确的，我认为合并会完美无缺。

采纳答案by John Bartholomew

Rename detection:

重命名检测：

My best guess is that rename detection is failing due to the very large number of candidates. The git source code is a little hard to follow in places, but it does appear that there are some hard-coded limits used in particular search steps of the rename detection algorithm (see diffcore-rename.c), as well as the configurable limit on the maximum number of pairs to look at (configuration keys diff.renameLimitand merge.renameLimit). This may be making detection fail even if you have set the configured limit suitably high. The configurable limit itself is clamped to the range [1, 32767].

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

Perhaps you can get around this by performing a restructuring step first: move files with git mv without making any content changes, to match the new layout, commit that on a new branch, and then replace it with your final version, which should have only content changes and no renames. Renames with no content changes mightbe detected more reliably. That's only practical if the restructuring you've done has been fairly simple, and I'm not certain that it will solve the rename detection failures.

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

Alternatively, perhaps you can split the changes up into separate commits with some simple file groupings, so that there are fewer candidates for rename detection in each commit.

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

Merging:

合并：

Unfortunately, by basing the new branch on top of master, you are giving git incorrect information about the merge. Independent of whether renames are correctly detected or not, when the newly created branch is merged with master it will overwrite everything in master, because from git's point of view, there are no changes in master that haven't already been included in the new branch.

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

回答by andrhamm

OS X is case-aware, but not sensitive. Git ?is? case-sensitive. If you changed a file name and the only change was a case change, rename the file back to the way it was, then use git mvto rename instead.

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

回答by BoD

Instead of git status, try git commit --dry-run -a, it detects renames better.

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

回答by Alex Onozor

Here is a perfect way to allow git know you rename a file.

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

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

Then git will pick up those changes.

然后 git 将接受这些更改。

Enjoy.

享受。

回答by sungiant

You could consider using git mvinstead: https://www.kernel.org/pub/software/scm/git/docs/git-mv.html

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

It has been much more reliable in my experience.

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

回答by Sergey Lukin

Whenever I had to rename/move files and forgot to tell GIT explicitly about it I used

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

git add . -A

which auto-detects files that were moved around

自动检测被移动的文件