我开始将 Maven 与 Web 应用程序项目一起使用,因此目录层次结构发生了变化。我为 Maven 集成创建了一个新分支。现在我有两个分支,一个具有旧目录层次结构,一个具有 maven 目录层次结构。两个分支都有新的提交(错误修复和新功能)。
我想摆脱旧分支并将其更改合并到 Maven 分支。Git 合并提供了无数感觉无法解决的冲突。我相信这是因为文件路径已经改变。
处理这种合并的最佳方法是什么?
尝试merge.renameLimit
将此合并设置为较高的值。git 尝试检测重命名,但前提是文件数低于此限制,因为它需要 O(n^2) 处理时间:
git config merge.renameLimit 999999
然后完成后:
git config --unset merge.renameLimit
博客文章“ Confluence, git, rename, merge oh my... ”添加了一些有趣的信息来说明Robie的答案(已投票):
当尝试检测重命名时,git 区分精确和不精确的重命名:
- 前者是重命名而不更改文件的内容和
- 后者是重命名,可能包括对文件内容的更改(例如重命名/移动 Java 类)。
这种区别很重要,因为用于检测精确重命名的算法是线性的,并且将始终执行,而用于不精确重命名检测的算法是二次的(
O(n^2)
),如果更改的文件数超过某个阈值(1000默认)。如果未显式设置,
merge.renameLimit
则默认为 1000 个文件或使用diff.renameLimit
if 设置的值。影响
,和while仅适用于合并尝试 ( , ) 。diff.renameLimit
git diff
git show
git log
merge.renameLimit
git merge
git cherry-pick
merge.renameLimit
更改而不是更改git是一个好主意,这样 git 在查看输出diff.renameLimit
等常见操作期间不会尝试查找重命名。git diff
要显示重命名,类似
git show
或的命令git log
可以与-M
打开重命名检测的选项一起使用。
是的,对于内核,我有
[diff]
renamelimit=0
完全禁用限制,因为默认限制确实非常低。Git 非常擅长重命名检测。
然而,低默认值的原因不是因为它不够灵活——而是因为它最终可能会使用大量内存(如果内存不足,交换将意味着它从“非常快”变为“像糖蜜一样慢” - 但它仍然不会受到 CPU 的限制,它只是疯狂地分页)。