mercurial - 自 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

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

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

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

init
1
3

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

Answer 1

为什么你进行三向 merge 的一个重要因素是你的上下文太人为了，我会解决这个问题。

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

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

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

如果我改为执行 hg backout 2 --merge ，它会自动将回退作为其要回退的修订的子级提交，然后将其与提示 merge ，在之后生成分支图我提交 merge :

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

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

init
1
3

而必须进行 3 路 merge ，因为更改太接近了。每个变更集中的上下文和更改完全重叠(差异 block 的默认上下文行数为 3 行，其中包含仍在第四个变更集中的整个文件)。

类似的示例是，如果您有 3 个变更集，每个变更集都修改同一行。如果您像在这里所做的那样取消了中间更改，您仍然会看到一个 3 路 merge ，您可能需要手动编辑它才能正确。

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

Before version 1.7, the behavior without --merge was equivalent to specifying --merge followed by "hg update --clean ." to cancel the merge and leave the child of REV as a head to be merged separately.

但是，我认为这并不完全是您所怀疑的。