自从写了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的书，如果我运行hg backout --merge 2，我应该：

init
1
3

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

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

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

init
1
3

我只是犯了一个错误或者错过了什么，或者我被这些选项卡住了？

Answer 1

你得到3-way合并的一个重要因素是你的上下文太人为了，我会讲到这一点的。

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

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

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

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

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

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

init
1
3

相反，必须进行三向合并是因为更改太接近了。每个变更集中的上下文和变更是完全重叠的( diff块的默认上下文行数是3行，这包含了仍然在第4个变更集中的整个文件)。

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

顺便说一句，行为在1.7中确实发生了变化，正如hg help backout所证明的那样

在

1.7之前的版本中，没有--merge的行为相当于指定--merge，然后指定"hg update --“。若要取消合并，请将REV的子项保留为要单独合并的头。

然而，我不认为这是你所怀疑的。