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

为什么你得到三向合并的一个重要因素是你的背景过于人为，我会谈到它。

如果我采用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

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

init
1
3

而是必须进行3向合并，因为这些变化太靠近了。每个变更集中的上下文和更改完全重叠（差异块的默认上下文行数为3行，其中包含仍在第4个变更集中的整个文件）。

类似的例子是，如果你有3个变更集，每个变更集都修改了同一行。如果您退出中间更改，就像您在这里做的那样，您仍然会看到一个3向合并，您可能需要手动编辑以获得正确的。

顺便说一句，行为确实在1.7中发生变化，如hg help backout所示：

在1.7版之前，没有--merge的行为等同于指定--merge后跟“hg update --clean”。取消合并，让REV的孩子成为单独合并的负责人。

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