如何在git中合并两个具有不同目录层次结构的分支？

Question

我开始将Maven与Web应用程序项目一起使用，因此目录层次结构发生了变化。我为Maven集成创建了一个新分支。现在我有两个分支，一个具有旧的目录层次结构，另一个具有maven目录层次结构。两个分支都有新的提交（错误修正和新功能）。

我想摆脱旧分支并将其更改合并到Maven分支。 Git merge会产生无数的冲突，感觉无法解决。我认为这是因为文件路径已经改变。

实现此合并的最佳方式是什么？

Answer 1

尝试将merge.renameLimit设置为此合并的高位。 git尝试检测重命名，但仅当文件数低于此限制时，因为它需要O（n ^ 2）处理时间：

git config merge.renameLimit 999999

然后完成：

git config --unset merge.renameLimit

Answer 2

博客文章＆＃34; Confluence, git, rename, merge oh my… ＆＃34;添加了一些有趣的信息，说明了Robie answer {upvoted）：

  

当尝试检测重命名时，git将完全重命名和不精确重命名区分为：

     

  
• 前者是重命名而不更改文件的内容和
  
• 后者是一个重命名，可能包含对文件内容的更改（例如，重命名/移动Java类）。
  

     

这种区别非常重要，因为用于检测精确重命名的算法是线性的，并且在不精确重命名检测的算法是二次方（O(n^2)）时将始终执行，并且如果文件数量，git不会尝试执行此操作更改超过某个阈值（默认为1000）。

     

未明确设置时，merge.renameLimit默认为1000个文件，如果设置，则使用diff.renameLimit的值。
  diff.renameLimit影响git diff，git show和git log，而merge.renameLimit仅适用于合并尝试（git merge，git cherry-pick）。< / p>      

最好更改merge.renameLimit而不是更改diff.renameLimit，以便git不会在常见操作中查找重命名，例如查看git diff输出。

     

要显示重命名，git show或git log等命令可与启用重命名检测的-M选项一起使用。

Linus mentions：

  

是的，对于内核，我有

    [diff]
            renamelimit=0

  

完全禁用限制，因为默认限制非常低。 Git非常擅长重命名检测。

     

然而，默认值低的原因并不是因为它不够活泼 - 因为它最终会占用大量内存（如果你的内存不足，交换意味着它会从＃34;非常活泼＆＃34;慢慢变成糖蜜＆＃34; - 但它仍然不会受到CPU的限制，它只是像疯了一样分页。