81

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

我想摆脱旧分支并将其更改合并到 Maven 分支。Git 合并提供了无数感觉无法解决的冲突。我相信这是因为文件路径已经改变。

处理这种合并的最佳方法是什么？

4

2 回答 2

174

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

git config merge.renameLimit 999999

然后完成后：

git config --unset merge.renameLimit
于 2011-01-18T09:53:40.733 回答
27

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

当尝试检测重命名时，git 区分精确和不精确的重命名：

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

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

如果未显式设置，merge.renameLimit则默认为 1000 个文件或使用diff.renameLimitif 设置的值。影响
,和while仅适用于合并尝试 ( , ) 。diff.renameLimitgit diffgit showgit logmerge.renameLimitgit mergegit cherry-pick

merge.renameLimit更改而不是更改git是一个好主意，这样 git 在查看输出diff.renameLimit等常见操作期间不会尝试查找重命名。git diff

要显示重命名，类似git show或的命令git log可以与-M打开重命名检测的选项一起使用。

莱纳斯提到：

是的，对于内核，我有

    [diff]
            renamelimit=0

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

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

于 2012-10-29T09:18:34.150 回答