mercurial – 自hg书写完以来,’hg backout`的行为是否发生了变

发布时间：2020-12-20 11:20:06 所属栏目：Python 来源：网络整理

导读：我创建了一个新的存储库,test-backout,并在其中添加了一个新文件file.然后我每次做4次提交,将提交的数量附加到文件使用 echo [manually entered number] filehg commit -m '[manually entered number]' 实际上,文件有： init123 根据hg书,如果我运行hg backo

我创建了一个新的存储库,test-backout,并在其中添加了一个新文件file.然后我每次做4次提交,将提交的数量附加到文件使用

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

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

解决方法

你获得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帮助退出所证明的那样：

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.

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!