git - merge 工具创建的 .orig 文件的预期用途是什么？

Question

Documentation没有说明为什么默认创建 .orig 文件。此外，它们在下一次 merge 后的内容是未定义的。不过，必须有一些默认创建它们的原因。

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

Answer 1

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

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

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

(git mergetool 命令有一个单独的配置旋钮，“trust exit code”，也用于相同的目的:尝试决定该工具是否实际上确实 merge 了文件。它使用这两种技巧来决定是否运行 git add。对于 git mergetool 知道的 merge 工具，它有一个内置的“信任退出代码”设置。显然，true 命令是一个糟糕的 merge 工具，并且不是内置的。)

如果我们将问题修改为:Why does git mergetool leave the .orig file behind by default? 那么我们必须问git mergetool 的作者为什么选择它作为默认。其实只有他们自己知道。我们可以推测:也许是因为 git checkout -m 可以在 merge 仍在进行的情况下重新创建冲突，当时作为命令不存在。也许是因为他们认为这是更方便的默认设置:rm *.orig 比运行 git checkout -m 更容易。但事实是，我真的不确定。