自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向合并的一个重要因素是你的上下文过于人为,我会谈到这一点.

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

而必须做三向合并是因为变化太接近了.每个变更集中的上下文和更改完全重叠(diff块的默认上下文行数为3行,其中包含仍在第4个变更集中的整个文件).

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

顺便说一下,1.7的行为确实发生了变化,如下所示hg help backout:

在1.7版之前,没有--merge的行为等同于指定--merge后跟"hg update --clean".取消合并并将REV的子女留作单独合并的负责人.

但是,我认为这不是你所怀疑的.