我们目前正在开发应用程序的新版本（2.0 版）。
我们有一位运行 1.0 版应用的客户发现了一个错误。我们更新了 1.0 版的标记变更集，并找到并修复了该错误。
我们提交了在源代码树中创建新头部的更改。
问题是如何最好地合并它？理想情况下，我希望将其合并到 1.0 版之后的变更集中。我不想将它合并到提示中，因为发现错误的代码实际上不再存在。
我意识到我可能应该为“v1.0 错误修复”创建一个单独的分支。
谢谢， 本
【问题讨论】：
标签： mercurial
当使用合并在存储库中移动更改时，所有关于您拥有更改的位置的最新共同祖先以及您想要它的位置。如果在进行此修复之前，您的 repo 看起来像这样：
[a]-[b]-[c]-[d]
如果 1.0 标记的变更集是 [b]，那么您现在有了这个：
[a]-[b]-[c]-[d]
\
-[e]
修复在[e] 中。 如果是这种情况，那么您只需要这样做：
hg update d
hg merge e
hg commit
然后你会得到这个：
[a]-[b]-[c]-[d]-[f]
\ /
-[e]-----
另一方面在进行更改之前，您的 repo 看起来像这样：
[a]-[b]-[c]-[d]
\
-[e]-[f]
1.0 抹布指向[f]，那么你现在有了这个：
[a]-[b]-[c]-[d]
\
-[e]-[f]-[g]
在[g] 中进行了修复。如果您想将变更集 [g] 移动到 [d] 而不带上 [e] 和 [f]，那么没有好的方法可以做到这一点。您可以使用的不太好的方法（称为cherrypicking）是使用hg export 和hg import 命令。
没有任何工作流程需要采摘樱桃，但要避免它需要一点深谋远虑。在第二种情况下，您可以通过不在 1.0 系列（作为[f] 的子代）上进行修复来避免它，而是作为您想要更改的两个地方的最近共同祖先的子代。由于您希望在 [d] 和 [f] 中都进行更改，因此您可以查找它们最近的共同祖先并看到它是 [b] 并使用以下命令进行更改：
hg update b
..edit..
hg commit
留下这张图：
[a]-[b]-[c]-[d]
\
\--[g]
\
-[e]-[f]
此修复，[g] 是一个新头，您可以将其合并到 [d] (2.0) 和 [f] (1.0) 中，而无需任何樱桃采摘。相应的命令是：
hg update d
hg merge g
hg commit
hg update f
hg merge g
hg commit
结果图是：
[a]-[b]-[c]-[d]--[h]
\ /
\--[g]----
\ \
-[e]-[f]-[i]
[h] 是您的新 2.0 修复，[i] 是您的新 1.0 修复。
总结：深思熟虑总是可以避免摘樱桃，但如果你不这样做，这不是世界末日
【讨论】：
听起来你有这个：
[a]-[b]-[v1]-[c]-[d]-[v2]
\
-[fix]
并希望在不合并 [fix] 中的任何更改的情况下摆脱多余的头部。
以下命令将简单地将分支标记为关闭，它不会被视为额外的头部，并且不会被 hg heads 和 hg branches 命令隐藏：
hg update fix
hg commit --close-branch -m "closed branch"
以下命令将“虚拟合并”额外的头部，丢弃任何更改。
hg update v2
hg --config ui.merge=internal:fail merge
hg revert --all --rev .
hg commit -m "dummy merge"
--config ui.merge=internal:fail 标志可防止合并工具尝试合并任何冲突，但不会阻止添加到另一个头的文件出现，因为不会与新添加的文件发生合并冲突。 revert 将简单地将所有文件更新回第一个父级的状态。你最终会得到：
[a]-[b]-[v1]-[c]-[d]-[v2]-[merge]
\ /
-[fix]-----------
但是[merge]的内容会和[v2]一样。
另一种进行虚拟合并的方法：
hg update v2
hg debugsetparents v2 fix
hg commit -m "dummy merge"
这会将工作目录设置为 v2，但随后“伪造”Mercurial，即 v2 和 fix 都是父级并将其作为合并提交。
【讨论】：