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

我开始在web应用程序项目中使用Maven，因此目录层次结构发生了变化。我为Maven集成创建了一个新分支。现在我有两个分支，一个是旧目录层次结构，另一个是maven目录层次结构。这两个分支都有新的提交（错误修复和新特性）

我想摆脱旧的分支，并将其更改合并到Maven分支。Git merge带来了无数感觉不可能解决的冲突。我认为这是因为文件路径已更改

---

进行此合并的最佳方法是什么？

尝试将

merge.renameLimit

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

git config merge.renameLimit 999999

完成后：

git config --unset merge.renameLimit

博客文章“”添加了一些有趣的信息，说明了的（投票结果）：

当试图检测重命名时，git通过以下方式区分精确重命名和不精确重命名：

• 前者是在不更改文件内容的情况下重命名的，并且
• 后者是一种重命名，可能包括对文件内容的更改（例如重命名/移动Java类）

这种区别很重要，因为检测精确重命名的算法是线性的，并且总是在检测不精确重命名的算法是二次的（

O（n^2）

）时执行，如果更改的文件数超过某个阈值（默认为1000），git不会尝试这样做

未显式设置时，

merge.renameLimit

默认为1000个文件，或使用

diff.renameLimit

的值（如果已设置）。

diff.renameLimit

仅影响

git diff

、

git show

和

git log

，而

merge.renameLimit

仅适用于合并尝试（

git merge

，

git cherry pick

）

与更改

diff.renameLimit

相反，更改

merge.renameLimit

是个好主意，这样git就不会在查看

git diff

输出等常见操作期间尝试查找重命名

要显示重命名，可以将

git show

或

git log

等命令与启用重命名检测的

-M

选项一起使用

:

是的，对于内核，我有

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

然而，低默认值的原因并不是因为它不够快，而是因为它最终可能会占用大量内存（如果内存不足，则交换将意味着它从“相当快”变为“像糖蜜一样慢”——但它仍然不会受到CPU的限制，它只是疯狂地分页）

---

正如其他读者所知：这些问题的典型错误消息是，

过多文件跳过不精确的重命名检测。

。注意：在增加renameLimit后，我必须运行“git merge--abort”，以便重试拉取。否则，这就成功了。

    [diff]
            renamelimit=0