Mercurial 在创建多头分支、重基和多个合并后，如何在不创建新头的情况下进行推送_Mercurial

Mercurial 在创建多头分支、重基和多个合并后，如何在不创建新头的情况下进行推送

mercurial

Mercurial 在创建多头分支、重基和多个合并后，如何在不创建新头的情况下进行推送,mercurial,Mercurial,我对共享存储库的本地副本执行了一系列愚蠢的步骤，我正在寻找一种方法来修复它。这些步骤是：我使用书签让一个开发分支有多个负责人，其他人使用： -o---o---o-----o--- <- dev branch \----1----1------ <- another head of the dev branch, where I committed stuff 你只能推一个你感兴趣的头mercurial。对你来说，这意

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

我使用书签让一个开发分支有多个负责人，其他人使用：
```
-o---o---o-----o---   <- dev branch
  \----1----1------   <- another head of the dev branch,
                         where I committed stuff
```
你只能推一个你感兴趣的头mercurial。对你来说，这意味着：
```
hg push -r f2033d695fcd
```
如果目标回购已更新，则需要拉取、合并和重新推送：
```
hg pull
hg up -r <remote head>
hg merge -r f2033d695fcd
hg ci
hg push
```
```
hg拉力
hg-up-r
hg合并-r f2033d695fcd
汞离子
汞推力
```
我解决了这个问题，没有将另一头推进回购，也没有将
```
23853bbf68df
```
合并到
```
newBranch
```
。这可能不是最干净的方法，但我将把它作为参考。简而言之，我通过获取所有提交并重新应用它们来重建整个分支
首先，我在我做的第一个发散版本中使用了strip，杀死了
```
newBranch
```
的头
```
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属于不同的分支，所以我不得不排除这些分支
```
现在，我在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 这可能并不适用于所有情况。在合并的过程中，我也不得不解决一些冲突，但相当温和。希望这对其他人有所帮助。不要使用徒手“绘图”-您可以使用控制台命令，并能够粘贴有问题的格式输出的命令（hg log 或hg glog ，例如，对于此处和处的树）。现在，请添加带有注释的hg heads 的输出-哪个head是过时的，不能存在（完全或仅在push target中）。另外，请阅读push commandHi@lazybager中的-r选项，我无法向您提供log 的输出，因为有比我描述的更多的提交，而且我还忘记了为了达到这种状态而执行的确切命令。。。问题已更新，以包含标题的输出。我不理解您对-r 选项的引用，它应该如何/为什么有帮助？在这种情况下不需要精确的命令-您（不是我）必须查看devBranch树（从807和820的共同父项到826），定义合并devBranch头的可能性（和必要性）。或者只需按下f2033d695fcd即可enough@LazyBadger，如果我尝试hg push-r f2033d695fcd--new branch ，我会得到abort:push在分支devBranch上创建新的远程磁头23853bbf68df 。这就是我试图避免的。至少合并这个头部（所有的都会更好）谢谢你的回答，但正如我提到的，这会产生中止：push在分支devBranch上创建新的远程头部23853bbf68df 。正如@lazybacker所建议的，我将尝试合并这个头部，尽管这是我想要避免的事情。这是一个不同于你实际试图推动的头部。如果使用-r指定要推送的磁头，则不会得到该磁头。 hg strip -r 646 hg export -g -r 797:808 -r 810 -r 815:822 -r 824:830 -o "%n-%m.patch" 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 hg strip -r 797