标记更改已经合并或故意忽略hg pull/push/merge/graft？

Question

我正在从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做类似的事情,所以如果我知道我永远不想合并给定的更改,我可以阻止它考虑,随后挑选樱桃,合并,等等,变得更加火上浇油.我做了很多谷歌搜索,但没有找到办法做到这一点.

似乎也无法查看尚未取消的更改列表.

因为我经常整理其他开发人员并帮助他们进行合并,所以能够做这些事情是非常有帮助的,人们可能会认为这是"反向挑选".即,标记您不想合并的更改,然后对剩余部分进行批量合并.

Answer 1

像Mercurial ans 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"

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