Question

我使用共享存储库的我的本地副本做了一系列愚蠢的步骤，我正在寻找一种方法来解决它。步骤是：

我使用书签来拥有开发分支的多个头，其他人使用：

-o---o---o-----o---   <- dev branch
  \----1----1------   <- another head of the dev branch,
                         where I committed stuff

我创建了一个新的分支，一段时间后仍然是本地的

  /---------------x   <- new branch
-o---o---o-----o---   <- dev branch
  \----1----1------   <- another head of the dev branch,
                         where I committed stuff

对于一个只包含我的代码的头，我在另一个分支上做了一个rebase

                   /-1'--1'--  <- rebase
  /---------------x            <- new branch
-o---o---o-----o---            <- dev branch
  \----1----1------            <- another head of the dev branch,
                                  where I committed stuff

然后，我合并了rebase，然后，几次提交，我合并了默认

                   ----------d-\      <-default
                                \
                   /-1'--1'\     \
  /---------------x--------x--x-x-x-- <- new branch 
-o---o---o-----o---         
  \----1----1------

现在，我想将我的新分支推送到服务器（hg push --new-branch -b newBranch），但我得到abort: push creates new remote head，因为提交1'属于dev分支。

正确的做法是什么？我想避免创建这个额外的头。

更新：

根据请求，这是hg heads：

的输出

changeset:   839:f2033d695fcd  <- want to push this
branch:      newBranch
tag:         tip
user:        me
date:        Wed Oct 31 13:05:51 2012 +0100

changeset:   826:7fde19d7f467
branch:      devBranch
user:        my-collegue
date:        Tue Oct 23 14:59:42 2012 +0200

changeset:   820:23853bbf68df  <- the part after rebase that got merged
branch:      devBranch
user:        me
date:        Mon Oct 22 15:36:26 2012 +0200

changeset:   807:899344cfb145  <- obsolete (branch with 1's)
branch:      devBranch
parent:      711:454f29c03fb1
user:        me
date:        Mon Oct 22 15:36:26 2012 +0200

changeset:   712:d5e8a62a7f5f  <- default, needs to stay
parent:      648:2bbcc01aa191
user:        me
date:        Wed Aug 22 16:21:09 2012 +0200

Answer 1

你只能推动你对mercurial感兴趣的一个头。对你而言，这意味着：

hg push -r f2033d695fcd

如果目标仓库已更新，则需要拉动，合并和重新推送：

hg pull
hg up -r <remote head>
hg merge -r f2033d695fcd
hg ci
hg push

Answer 2

我解决了这个问题，没有将另一个头推到回购站，也没有将23853bbf68df合并到newBranch上。这可能不是最干净的方法，但我会将其作为参考。简而言之，我通过完成所有提交并重新应用它来重建整个分支。

首先，我通过在我做的第一个分歧版本上使用条带来杀死newBranch'es head 899344cfb145：

hg strip -r 646

然后，我为newBranch中的所有提交生成了电子邮件补丁（无法使用mq），因为它已经开始了：

hg export -g -r 797:808 -r 810 -r 815:822 -r 824:830 -o "%n-%m.patch"

797:808是newBranch中的补丁，位于devBranch（1'从原图中提交的重新定位部分）。
810和815:822是newBranch中的其他补丁。 811:814属于不同的分支，因此我必须排除这些分支。
823是default的合并提交，所以我跳过了这个。
824:830是与default合并后的所有提交。

现在，我在newBranch的新头上导入了这些补丁：

hg up -r 796
# there are 29 patches, applying till merge
hg import --bypass {01..21}*.patch
hg up tip
hg merge default
hg ci -m 'merging in default'
hg import --bypass {22..28}*.patch

最后，我刚刚剥离了newBranch的原始头部。

hg strip -r 797

这可能不适用于所有情况。在合并期间，我也必须解决一些冲突，但非常温和。希望这有助于某人。

在创建多头分支，rebase和几个合并之后，如何在不创建新头的情况下进行推送

2 个答案: