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

尝试将此合并设置为较高的 merge.renameLimit。 git 尝试检测重命名，但前提是文件数低于此限制，因为它需要 O(n^2) 处理时间：

git config merge.renameLimit 999999

然后完成后：

git config --unset merge.renameLimit

---

博文“Confluence, git, rename, merge oh my… ”添加了一些有趣的信息来说明 Robie 的 answer（已投票）：

当尝试检测重命名时，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）。更改 merge.renameLimit 而不是更改 diff.renameLimit 是个好主意，这样 git 就不会在查看 git diff 输出等常见操作期间尝试查找重命名。要显示重命名，可以将 git show 或 git log 等命令与 -M 选项一起使用，以打开重命名检测。

Linus mentions：

是的，对于内核，我有

    [diff]
            renamelimit=0

完全禁用限制，因为默认限制确实非常低。 Git 非常擅长重命名检测。然而，低默认值的原因不是因为它不够灵活——而是因为它最终可能会使用大量内存（如果内存不足，交换将意味着它从“非常快”变为“像糖蜜一样慢” - 但它仍然不会受到 CPU 的限制，它只是疯狂地分页）。

---