Mercurial 反复无常,只拉一根树枝

Mercurial 反复无常,只拉一根树枝,mercurial,Mercurial,我有两份Mercurial回购协议C1和C2,这两份协议不久前都来自同一母公司p,但后来有了不同的发展方向。此外,在C2中,有一个命名的分支B2,发生在改道之后。我只想把分支B2拉入C1,我可以很容易地用hg拉C2——分支B2 现在B2从C2回购的默认分支中的一些点分支出来。所以,这些来自C2的默认变更集被拉到C1中,即使我只是尝试拉分支B2。(我可以理解,因为他们是B2变更集的祖先) 在上面的拉取之后,我将在C1的默认分支上有两个头部,原始头部和由那些默认变更集组成的头部,这些默认变更集由于拉

我有两份Mercurial回购协议C1和C2,这两份协议不久前都来自同一母公司p,但后来有了不同的发展方向。此外,在C2中,有一个命名的分支B2,发生在改道之后。我只想把分支B2拉入C1,我可以很容易地用hg拉C2——分支B2

现在B2从C2回购的默认分支中的一些点分支出来。所以,这些来自C2的默认变更集被拉到C1中,即使我只是尝试拉分支B2。(我可以理解,因为他们是B2变更集的祖先)

在上面的拉取之后,我将在C1的默认分支上有两个头部,原始头部和由那些默认变更集组成的头部,这些默认变更集由于拉取B2而被拉取。我想保持C1的默认分支不变,否则我会有两个头,不断有人告诉我更新“交叉分支”,并告诉我必须合并。(我将从未来的其他外部回购中,将新的违约分支机构纳入C1)


我如何才能做到以上几点,这样我就不会有两个默认值?

想想这个问题,我认为你有这样的想法是对的吗

@  4[tip]:1   439255c536ee   2013-01-25 10:42 +0000   rob
|    More changes on original default branch
|
|   o  3   379f384c1d73   2013-01-25 10:41 +0000   rob
|   |   Changes on named branch B2
|  /
| o  2:0   d225da266931   2013-01-25 10:40 +0000   rob
| |    Changes on cloned default
| |
o |  1   7088660d3ba6   2013-01-25 10:41 +0000   rob
|/     Changes on original default branch
|
o  0   a02a921256b3   2013-01-25 10:39 +0000   rob
     Project Start
您所描述的问题是,虽然您希望保留
B2
分支,但不希望在
default
上有两个头:

$ hg heads default --style=compact
4[tip]:1   439255c536ee   2013-01-25 10:42 +0000   rob
  More changes on original default branch

2:0   d225da266931   2013-01-25 10:40 +0000   rob
  Changes on cloned default
我可以看到两种可能性来“修复”这个问题。一种是简单地关闭“克隆”的默认分支(至少在您的回购中):

这意味着如果您发出一个
hg update default
,它不应该是含糊不清的,我想这是问题的一部分

另一种方法是从另一个默认分支执行“”:

$ hg update
$ hg -y merge --tool=internal:fail 2
$ hg revert --all --rev .
$ hg resolve -a -m
$ hg commit -m "Merged cloned default"
这些方法的主要区别在于,使用
--close branch
选项时,在使用
hg heads-c
时仍然可以看到额外的头。。。它仍然是一个头部,但它只是在元数据中设置了一个标志,表示它已关闭。您仍然可以更新已关闭的分支,甚至提交对其所做的更改。进行合并时,您将根本看不到头部,因为它不再是头部

这两种方法都意味着您仍然可以将更改拉入B2分支-但是,如果在回购中您从中拉入,他们会在默认情况下进行更改,并将这些更改合并到B2中(通常在修复错误等时使用),您将在稍后遇到相同的问题,并且必须重复上述操作


我希望这是有道理的。当然,如果您以后推动另一个回购,您也将推动关闭/合并的变更集。明智的做法是克隆您的回购协议,并在本地尝试这些方法,以检查这是否是您真正想要的。

将B2拉入C1不会自动在C1中创建B2的分支,与C2中的分支相同吗?谢谢,这似乎可行,而且比我尝试的重定基法简单得多。我没有意识到你可以关闭一个不知名的分支,非常有用。我注意到,当我最终推送到主repo(使用push--new分支)时,仍然有一条消息说push创建了一个新的远程头,但我使用了-f,并且在将来的hg更新等方面没有问题。如果使用空合并选项,就不应该得到“push创建一个新的远程头”。然而,创建一个新的远程磁头的问题是,它会产生歧义——“我应该更新到什么?”。因此,如果您关闭了分支,它将消除这种歧义。
$ hg update
$ hg -y merge --tool=internal:fail 2
$ hg revert --all --rev .
$ hg resolve -a -m
$ hg commit -m "Merged cloned default"