5

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

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

    -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

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

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

  • 然后，我合并了变基，然后，在几次提交之后，我合并了默认值

                       ----------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'属于开发分支。

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

更新：

根据请求，这是以下输出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
4

2 回答 2

7

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

hg push -r f2033d695fcd

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

hg pull
hg up -r <remote head>
hg merge -r f2033d695fcd
hg ci
hg push
于 2012-10-31T21:13:36.153 回答
1

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

首先，我杀死了newBranch'es head 899344cfb145，在我做的第一个分歧修订中使用了 strip ：

hg strip -r 646

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

hg export -g -r 797:808 -r 810 -r 815:822 -r 824:830 -o "%n-%m.patch"
  • 797:808是在（原始图的提交）newBranch的重新基础部分中的补丁。devBranch1'
  • 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

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

于 2012-11-02T13:13:34.573 回答