3

我创建了一个新的存储库，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

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

4

1 回答 1

7

为什么你得到 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

在这两种情况下，我都不必进行任何 3 路合并。你没有自动得到的原因

init
1
3

而是必须做一个 3-way 合并是更改太靠近在一起。每个变更集中的上下文和更改完全重叠（差异块的默认上下文行数为 3 行，其中包含仍在您的第 4 个变更集中的整个文件）。

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

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

在 1.7 版之前，没有 --merge 的行为等同于指定 --merge 后跟“hg update --clean”。取消合并，将 REV 的子节点作为头部单独合并。

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

于 2011-08-17T05:05:32.907 回答