git - 合并工具创建的 .orig 文件的预期目的是什么？

Question

文档没有说明.orig默认创建文件的原因。此外，它们在下一次合并后的内容是未定义的。尽管如此，必须有一些理由默认创建它们。

我最好的猜测是，纠正失败的合并很常见，并且在存在现有.orig文件时也更容易（而不是重复合并），但显然大多数用户不知道如何处理它们。

Answer 1

并不是它们是默认创建的，而是它们被默认留下。在运行您选择作为合并工具的命令之前，该git mergetool命令始终将冲突标记文件复制到 a 。.orig

该git mergetool命令创建它们的真正原因是它可以将所谓的合并文件上的日期戳与.orig它最近创建的文件上的日期戳进行比较。

假设git mergetool运行的命令应该合并三个基本文件、本地 ( HEAD/ --ours) 和远程 ( --theirs) 文件，但实际上什么也没做。例如，假设您选择了 command true，这是一个简单成功的无操作。在这种情况下，命令未写入的“合并”文件具有与创建时相同的时间戳git mergetool。同时，该.orig文件还具有与制作时相同的时间戳git mergetool。这表明git mergetool您选择的合并工具实际上失败了，并且文件实际上并没有真正合并。如果假定合并的文件比.orig文件，但是，那么您选择的命令必须已写入文件，因此它现在可能已按照您想要的方式合并。

（该git mergetool命令有一个单独的配置旋钮，“信任退出代码”，也用于相同目的：尝试确定该工具是否确实合并了文件。它使用这两个技巧来决定是否运行git add。对于知道的合并工具git mergetool，它有一个内置的“信任退出代码”设置。显然，该true命令是一个可怕的合并工具，并且没有内置。）

如果我们将问题修改为：为什么默认git mergetool保留.orig文件？然后我们必须询问作者git mergetool为什么选择它作为默认值。只有他们真正知道。我们可以推测：也许是因为git checkout -m在合并仍在进行的情况下可以重新创建冲突的 ，当时并没有作为命令存在。也许是因为他们认为这是更方便的默认设置：它rm *.orig比运行更容易git checkout -m。但事实是，我真的不确定。

Answer 2

如果我没记错的话，当文件发生冲突时，为了能够看到发生了什么，只需查看文件，因为它们位于您尝试合并的分支的尖端，这不是在某些情况下就足够了，因此原始文件就是分支分歧点上的文件（这样您就可以看到所涉及的两个分支中的每一个的差异）。

Answer 3

它们是来自不成功合并的备份文件。扩展来自程序补丁；在手册中查找“.orig”。