自从编写 hg 书以来，`hg backout` 的行为是否发生了变化？

Question

我创建了一个新的存储库test-backout，并在其中添加了一个新文件file。然后我每次进行 4 次提交，使用

将提交的编号附加到 file

echo [manually entered number] >> file
hg commit -m '[manually entered number]'

实际上，文件有：

init
1
2
3

根据hg book，如果我运行hg backout --merge 2，我应该有：

init
1
3

但相反，它无法合并并打开我的 difftool (vimdiff)，我得到 3 个选项：

init          | init          | init
1             | 1             |
2             |               |
3             |               |

我最初尝试使用--merge 选项，然后再次没有它。我现在的问题是，我还有办法得到：

init
1
3

我只是犯了一个错误或错过了什么，还是我坚持这些选项？

Answer 1

您获得 3 路合并的一个重要因素是您的上下文过于人为，我会谈到这一点。

如果我使用一个 50 行的文本文件并更改不同的部分并提交每个更改，我就不必解决冲突。我的意思是我有 4 个变更集：rev 0 添加文件，revs 1、2 和 3 分别更改文件的一个区域：开头、中间或结尾。

在这种情况下，当我执行 hg backout 2 时，它会反转 rev 2 并将这些更改合并到我的工作目录中，当我提交时，图表是线性的：

@  backout 2
|
o  3
|
o  2
|
o  1
|
o  initial

如果我改为使用hg backout 2 --merge，它会自动将回退作为它正在回退的修订的子版本提交，然后将其与提示合并，在我提交合并后生成一个分支图：

@    merge
|\
| o  backout 2
| |
o |  3
|/
o    2
|    
o    1
|    
o    initial

在这两种情况下，我都不需要进行任何 3 路合并。你没有自动得到的原因

init
1
3

而必须做一个 3-way 合并是更改过于靠近。每个变更集中的上下文和更改完全重叠（差异块的默认上下文行数为 3 行，其中包含仍在您的第 4 个变更集中的整个文件）。

一个类似的例子是，如果您有 3 个变更集，每个变更集都修改了同一行。如果您像在此处所做的那样退出中间更改，您仍然会看到一个 3 路合并，您可能必须手动编辑才能正确。

顺便说一句，行为在 1.7 中确实发生了变化，hg help backout 证明了这一点：

在 1.7 版之前，没有 --merge 的行为等同于指定 --merge 后跟“hg update --clean”。取消合并，将 REV 的子节点作为 head 单独合并。

不过，我不认为这正是你所怀疑的。