如何在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

博客文章" Confluence,git,rename,merge oh my my ... "添加了一些有趣的信息,说明了Robie的回答(upvoted):

当试图检测重命名时,git区分精确和不精确的重命名:

• 前者是重命名而不改变文件的内容和
• 后者是一个重命名,可能包括对文件内容的更改(例如重命名/移动Java类).

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

未明确设置时,merge.renameLimit默认为1000个文件或使用diff.renameLimitif set 的值.
的diff.renameLimit影响git diff,git show并git log同时merge.renameLimit适用于合并的尝试(git merge,git cherry-pick)只.

改变它是一个好主意,merge.renameLimit而不是更改,diff.renameLimit以便git不会在常见操作中查找重命名,例如查看git diff输出.

要显示的重命名,指令等git show或git log可以与被使用-M,轮流重命名检测选项.

Linus提到:

是的,对于内核,我有

    [diff]
            renamelimit=0

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

然而,低默认值的原因不是因为它不够活泼 - 这是因为它最终会占用大量内存(如果内存不足,交换意味着它会从"相当快速"变为"像糖蜜一样慢" - 但它仍然不会受到CPU的限制,它只是像疯了一样分页.