使用 hg pull/push/merge/graft 将更改标记为已合并或故意忽略？答案

【问题标题】：Mark changes as already merged or deliberately ignored with hg pull/push/merge/graft?使用 hg pull/push/merge/graft 将更改标记为已合并或故意忽略？
【发布时间】：2012-01-25 00:15:04
【问题描述】：

我正在从 Subversion 过渡到 Mercurial，我习惯使用 svnmerge.py 来跟踪已经合并或被阻止合并的更改：

# Mark change 123 as having already been merged; it will not be merged again, even if a range
# that contains it is subsequently specified.
svnmerge.py merge -M -r123
#
# Block change 326 from being considered for merges.
svnmerge.py merge -X -r326
#
# Show changes that are available for merging from the source branch.
svnmerge.py avail
#
# Do a catchall merge of the remaining changes.  Neither change 123 nor change 326 will be
# considered for merging.
svnmerge.py merge

我希望能够为 hg pull/push/merge/graft 做类似的事情，这样如果我知道我永远不想合并给定的更改，我可以阻止它考虑，进行后续的挑选，合并等，成为一个更加“一劳永逸”的事情。我做了很多谷歌搜索，但还没有找到方法。

似乎也无法查看尚未移植的更改列表。

由于我经常在其他开发人员之后进行整理并帮助他们进行合并，因此能够做这些事情非常有帮助，人们可能会认为这是“逆向挑选”；即，标记您不想合并的更改，然后对其余部分进行批量合并。

【问题讨论】：

MG 在下面有你的答案，他 TL；DR 版本是：基于 DAG 的系统（Mercurial、Git 等）在跟踪合并的内容方面做得很好，只要你避免挑选（无论是 git 还是 Mercurial 都不能很好地处理——按照设计），那么已经合并的和需要合并的就会自行解决。
唉，在 $REALWORLD 中，您最终会得到一个用于当前开发的分支和一个或多个代表稳定待定发布和已发布和现场发布的分支，并且可能有很可能是这些分支内的故意分歧。您希望平凡的错误修复可以轻松地从一个分支转移到另一个分支，但您不这样做；例如，希望新功能流向稳定或支持分支，并且您不希望解决当前开发分支中修复的错误的配置更改从支持分支流回。
如果我的生活不是 $REALWORLD，我需要更好的幻想。您描述的情况在非移植模式下效果很好。尝试观看 2011 年fogbugz 世界巡演的视频，其中@bmp 将引导您完成将修复程序合并到多个发布版本中，所有这些都无需使用命名分支或移植。只要您修复了添加它的修订的子版本（hg bisect 很容易找到），您就可以使用hg merge 将其拉到任何版本或待定版本中，而无需带 any 其他变更集。
我在已经很长的答案中添加了一些内容...@Ry4an 说得对，他说如果您知道三向合并的规则并因此合并，您可以获得一个很好的工作流程向前，而不是向后。
我不怀疑你是对的，而且对于一个认真、专业的 hg 用户来说，你的方法会奏效。我有点希望，因为 SCM 人员很可能是唯一在多条开发线之间进行批发（即非嫁接）合并的人。我曾希望有一些东西可以用来简化“天真” hg 用户的流程，但似乎没有。还有“PITA Fred”的案例，他设法搞砸了一切。每个组织都有其中一个，因此制定流程来限制他可以造成的损害非常重要。

标签： mercurial merge dvcs cherry-pick

【解决方案1】：

像 Mercurial 和 Git 这样的基于 DAG 的系统要么全有，要么全无：当您合并两个分支时，您会对共同祖先和两个分支进行三向合并。

三路合并仅与每个分支的最后阶段有关。例如，如果您在 10 到 1000 步中进行更改并不重要 — 合并结果将是相同的。

这意味着忽略变更集的唯一方法是在合并之前将其退出：

$ hg backout BAD

这将取消分支上的变更集，从三向合并的角度来看，它似乎从未被创建过。

如果您有一个想要合并但忽略的整个分支，那么您可以进行 虚拟合并：

$ hg merge --tool internal:local --non-interactive
$ hg revert --all --rev .

这会通过合并，但会在提交之前恢复到旧状态。

我能给您的最佳建议是构建您的工作流程，这样就不需要上述回退。这意味着在最旧的应用程序分支上提交错误修复。如果在创建功能 X 时发现错误，则使用hg bisect 找出错误是何时引入的。现在更新回您仍要修复错误的最旧分支：

$ hg update 2.0
# fix bug
$ hg commit -m "Fixed issue-123"

然后将错误修复合并到所有以后的分支中：

$ hg update 2.1
$ hg merge 2.0
$ hg commit -m "Merge with 2.0 to get bugfix for issue-123"

$ hg update 2.2
$ hg merge 2.1
$ hg commit -m "Merge with 2.1 to get bugfix for issue-123"

如果错误修正不再适用，那么您应该仍然合并，但丢弃不相关的更改：

$ hg update 3.0
$ hg merge 2.2 --tool internal:local --non-interactive
$ hg revert --all --rev .
$ hg commit -m "Dummy merge with 2.2"

这确保您可以随时使用

$ hg log -r "::2.2 - ::3.0"

查看 2.2 分支上尚未合并到 3.0 中的变更集。

【讨论】：