GIT GIT 版本不同合并结果不同

Question

在不同的 GIT 版本上运行合并命令我们得到不同的结果：

命令是： git merge --no-ff origin/master_codeline

结果：

• 版本 2.1.4 -> 合并成功
• 版本 1.7.1 -> 同一提交上的同一合并命令返回冲突（CONFLICT（重命名/添加））

现在只需更新操作系统上的 GIT 版本就很容易了，但是 1.7.1 是我们的操作系统支持的最新工作版本（Linux 2.6.34.10-0.2-xen SMP 2011-07-20 GNU/Linux，openSUSE 11.3（ x86_64) VERSION = 11.3) 并且我们无法更新操作系统，因为我们有一些限制。

我想知道是否有人遇到过此类问题，最终是否有解决方法，也许可以调整 GIT 默认合并选项。

冲突 output 是：

CONFLICT (rename/add): Rename src/test/resources/env/env_branch2_jboss.prop->src/test/resources/env/dev2.prop in HEAD. src/test/resources/env/dev2.prop added in origin/master_codeline
Adding as src/test/resources/env/dev2.prop~origin_master_codeline instead
CONFLICT (rename/add): Rename src/test/resources/env/jboss.properties->src/test/resources/env/dev3.prop in HEAD. src/test/resources/env/dev3.prop added in origin/master_codeline
Adding as src/test/resources/env/dev3.prop~origin_master_codeline instead
Automatic merge failed; fix conflicts and then commit the result.

不幸的是，我们遇到这些问题的 VM 是我们的自动化机器，我们在该 VM 上运行大部分合并操作。

Answer 1

您可以使用git status检查详细信息合并冲突文件。 这主要是因为某些文件显示为已删除/添加，而某些文件显示为未合并的路径。

您只需要使用以下命令来完成重命名的合并冲突 ：

git add .
git commit

Answer 2

您应该使用 2.31+ Git 版本再试一次，该版本默认为新的 ORT 合并策略。

在 Git 2.36（2022 年第 2 季度）中，消息“ort”合并后端在处理冲突路径时的准备工作更加清晰，并且区分了内部合并和外部合并。

请参阅Elijah Newren ( newren )的提交 4a3d86e （2022 年 2 月 17 日）。
^{（由Junio C Hamano 合并gitster 提交 b3db182，2022年 2 月 25 日）}

merge-ort ：使来自递归合并的信息消息更清晰

^{签字人：Elijah Newren}

这是另一个简单的变化，有很长的解释......

merge-recursive 和 merge-ort 都基于相同的递归思想：如果有多个合并基，则合并合并基（可能需要先合并合并基的合并基等）。
内部合并的深度通过一个名为"call_depth",我们稍后会再次提到它。
自然地，内部合并本身可能会产生冲突并生成有关这些文件的各种消息。

merge-recursive 会立即打印到 stdout，冒着为彼此相距很远的同一路径打印多个冲突通知的风险，以及它们之间的其他路径的许多中间冲突通知。
即使不涉及内部合并也是如此。
这个线程中给出了一个这样的例子，显然引起了一些混乱：

 CONFLICT (rename/add): Rename A->B in HEAD. B added in otherbranch...dozens of conflicts for OTHER paths... CONFLICT (content): Merge conflicts in B

相反，merge-ort 收集消息并按路径存储它们，以便它可以按路径分组打印它们。
因此，由 merge-ort 处理的相同案例将具有以下形式的 output：

 CONFLICT (rename/add): Rename A->B in HEAD. B added in otherbranch CONFLICT (content): Merge conflicts in B...dozens of conflicts for OTHER paths...

这通常是有帮助的，但确实会使单独的错误更成问题。
特别是，虽然 merge-recursive 可能会为递归合并报告以下内容：

 Auto-merging dir.c Auto-merging midx.c CONFLICT (content): Merge conflict in midx.c to-merging diff.c to-merging dir.c NFLICT (content): Merge conflict in dir.c

merge-ort 会报告：

 Auto-merging diff.c Auto-merging dir.c Auto-merging dir.c CONFLICT (content): Merge conflict in dir.c Auto-merging midx.c CONFLICT (content): Merge conflict in midx.c

同一文件的消息放在一起这一事实通常可能有帮助，但不幸的是，由于内部合并缺少缩进，它会造成混淆。
这可能会让用户想知道：

• 为什么 Git 报告“ dir.c ”被合并两次？
• 如果midx.c有冲突，为什么我打开文件时没有看到任何冲突，为什么索引中没有显示冲突？

通过更改 output 以明确区分外部合并消息和内部合并消息来解决此 output 混淆问题，将上述 output 从 merge-ort 更改为：

 Auto-merging diff.c From inner merge: Auto-merging dir.c Auto-merging dir.c CONFLICT (content): Merge conflict in dir.c From inner merge: Auto-merging midx.c From inner merge: CONFLICT (content): Merge conflict in midx.c

（注意：'From inner merge:' 后的空格数是2*call_depth) 。