git无法检测重命名 [英] git fails to detect renaming

问题描述

一个分支（ refactoringBranch ）具有完整的目录重构。

我试图合并：
git merge --no-ff -Xrename -threshold = 15 -Xpatience -Xignore-space-change重构分支


git状态显示大约一半的文件重命名识别。但项目中的10000个文件中没有一个被识别为移动。

一个例子是：

 ＃分支master 
＃要提交的更改：
 
＃已删除：404.php 
＃新文件：public_html / 404.php 
 ... 
＃已删除：AnotherFile .php 
＃新文件：public_html / AnotherFile.php 
 ... 
＃已重命名：contracts / css / view.css  - > public_html / contracts / css / view.css 
  

建议？

---

史前史

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

1. 创建源自重构分支 >主。


2. 删除了重构分支中已更改的结构，这意味着我在其他一些目录中进行了更改，并将它们复制粘贴到我的git上库。


$ b
3. 这是我的工作流程：

     git checkout -b重构分支
    cp -R other / place / * ./ 
    git add。 -A 
    git commit -a -mblabla
    git checkout master 
    git merge --no-ff -Xrename-threshold = 15 -Xpatience -Xignore-space-change refactoringBranch 
     

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

   重命名检测：
   
   
   

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

   也许你可以通过首先执行重组步骤来解决这个问题：用git mv移动文件而不用任何内容都会更改，以匹配新布局，在新分支上进行提交，然后将其替换为最终版本，该版本只应更改内容并且不能重命名。在没有内容更改的情况下进行重命名可以更可靠地检测到可能。如果你所做的重组相当简单，那么这是唯一可行的，但我不确定它会解决重命名检测失败的问题。
   另外，也许你可以将更改拆分为具有一些简单文件分组的独立提交，这样每次提交中重新命名检测的候选人就会减少。
   
   
   

   合并：

   
   
   

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

   
   

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

   I tried to merge: 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.

   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:

   1. Created the refactoringBranch originating 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.

   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 . -A step probably. Because if rename detection was correct there, I'd assume the merge would go flawless.

   解决方案

   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.renameLimit and 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].

   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 might be 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.

   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.

   这篇关于git无法检测重命名的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！