自 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< /code>，我应该有：

init
1
3

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

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

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

init
1
3

我是否犯了错误或错过了什么，或者我是否坚持这些选择？

Answer 1

为什么你进行三向合并的一个重要因素是你的上下文太人为了，我会谈到这一点。

如果我获取一个 50 行文本文件并更改不同的部分并提交每个更改，我将不必解决冲突。我的意思是我有 4 个变更集：版本 0 添加文件，版本 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 行，其中包含仍在第四个变更集中的整个文件）。

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

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

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

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