在第24版中，我为一个新功能创建了一个分支，同时，其他人继续使用默认设置（转速为26,28和29）但最终导致项目处于不良状态。我一直在分支上进行开发（直到第36版），现在应该成为默认分支。我该怎么做？
我尝试在默认情况下回到24并与36合并，并且我在默认情况下获得了37就像我想要的那样。但现在它抱怨有两个头（37和29）。我不想合并，因为26,28和29都不好。我试着去37并做hg merge --tool internal：local -r 29丢弃29，但它没有用。
这似乎很简单，但我有点卡住了。
提前致谢
答案 0 :(得分：1)
解决此问题的一种方法是关闭您不想要的分支：
hg update 29
hg commit --close-branch -m "closing branch"
从技术上讲，你仍然会有两个头，但是一个会被标记为已关闭，所以你不会注意到它在一般情况下使用（例如你运行hg heads）。
或者，我猜你在哪里声明mercurial“抱怨有两个脑袋”，那就是当你试图推送到另一个存储库时。在这种情况下，您可以指定是，您确实知道新头并接受它存在。如果在将分支标记为已关闭后执行此操作，则不应导致任何问题：
hg push --force
然而，当您进行更新时，您可能会产生歧义，因此在这种情况下指定修订版本可能是个好主意。
最后，如果您不希望看到未合并到自己的分支中的变更集，则可以在克隆到新存储库时指定自己的最新版本：
hg clone project new_project --rev 37
我认为这将创建一个仅包含进入该修订版所需的更改集的克隆。然后，您可以将此作为工作的基础。缺点是你不会有你可能真正想要的非祖先变更集。
对于其他选项，我会研究Mercurial打包的一些扩展，例如strip。我没有用过这个，所以不能给你任何建议。
您可以查看here以获取更多信息。
答案 1 :(得分：1)
克劳迪奥，我会尝试将您的问题“翻译”成更干净的形式（如果需要，请检查翻译和修订）
您在第24版已命名的default分支中创建了匿名分支，现在您只想在开发中使用来自另一个树的某些变更集，并且在推送到远程服务器时遇到问题关于创建额外的头部。
我的重建是否正确？
如果“是”和不需要的变更集26,28,29处于单个连续范围内，您可以合并“最后一个好”的外部变更集（合并24无用，没有glog的AFAICS - 它似乎是分支点）并关闭不需要的头： @icabod与--close-branch recipe
是正确的从另一方面来说，如果您的存储库是唯一的并且未发布，您可以重写历史记录（MQ：strip，histedit ...）并在合并删除错误的变更集之前，获取干净的第二个匿名分支，合并，提交，推送
您也可以（虽然不推荐）push -f，并且将两个头推到远程仓库，当您和其他人使用它时，您的头部将处于活动状态
通过评论照片修复
更正重建，迭代2：您在默认分支中有一些更改集，您希望从主线中排除这些更改并将您的分支合并为默认值。
除了建议的早期历史记录重写（从历史记录中完全删除变更集 - 适用于“未发布”存储库），您可以在历史记录中保留错误的变更集，但撤消其更改以获取其他变更集的成本：hg backout -r REV创建变更集，撤消REV的变化（不记得在这里使用revrange）。默认情况下有三个（最大）新的退出更改集，您可以将分支合并为默认值（即使合并后也可以退出）。
答案 2 :(得分：0)
基本上你需要（a）将default恢复到它在修订版24中的状态（不破坏任何历史记录），然后（b）将你的特征分支合并回默认值。你通过在默认情况下创建两个头来复杂化一些东西，但没有大问题。让我们一步一步。
（我建议克隆你的整个仓库以便你可以安心地试验。如果你做了一些你不喜欢的事情，只需删除整个目录并重新开始）。
以下是如何扭转被误导的更改的效果（不使用破坏性地重写历史记录的strip之类的命令）：
更新到默认负责人：
hg update -r 29
在不更改“当前”版本的情况下，将所有文件切换为修订版24中的文件：
hg revert -r 24
将此文件状态提交为default的新头：
hg commit -m "Backing out revisions 26,28,29"
此时，你可以将你的功能分支合并到default的新头上，因为所有错误的更改都已被撤消：
hg merge feature
这应该是故事的结尾。但是你已经将feature合并到rev 24中，获得了revset 37.没问题，你仍然可以执行步骤1-3，这将为你提供一个没有破坏性更改的默认头。然后，不是合并feature的头部，而是合并37作为最后一步：
hg merge -r 37
这将统一default的负责人，没有任何负面影响，因为你已经退出了被误导的变化。