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