我对主（也是唯一）分支进行了一些更改（A）。然后我的同事做了一些其他的改变（B）。然后我发现变化（A）无可救药地被打破了，我决定完全放弃它们。另一方面，变化（B）非常好，幸运的是完全独立于chanegs（A）。变化（B）的体积远小于变化（A）。
通常，我只是hg commit --close-branch为described here。但后来我失去了更改（B），并且需要在新的活动分支中重新创建它们。我可以这样做，只需识别受影响的文件（手工），然后更新（手工），然后提交。这显然不是完美的，因为它需要两个手动步骤，并且还会在存储库中产生误导性提交（误导，因为我的同事不久前做出了更改，但看起来好像是我今天制作的）。我想这不是世界末日，但有更优雅的解决方案吗？
注意：如果Mercurial支持将只是差异从一个提交应用到修订树中的另一个位置，那么它就可以了。但我怀疑这个功能不存在，原因很简单：当逐字地应用于另一个父变更集时，差异与现有父变更集非常有用。
答案 0 :(得分：3)
--close-branch有另一个理由，而不是丢弃糟糕的变更集hg help backout反向更改中提供“撤消变更集”，阅读hg backout CSET-HASH来撤消先前历史记录中显示的任何变更集，在CSET-HASH中执行以获取额外提交的成本回购使用backout来查杀旧变更集的效果（rev.7 undo rev.3）
>hg log -r 3:7 --template "{rev}:{node|short}\n{desc}\n\n"
3:2f09429039a6
Немного более русские даты
4:97419f57d7db
Заготовки под перевод
5:674a76db96fd
UTF8 и перевод assigncategories
6:9cd6b52df09f
Подчистки локализации
7:c2a2812d11ad
Backed out changeset: 2f09429039a6
hg help graft（基于合并的注入逻辑而不是旧的hg transplant）。有用性或无用性是人类选择的问题，嫁接变更集在新父母之上的可行性（没有合并冲突）是移植本身的责任如果移植合并导致冲突，移植过程将被中断，以便可以手动解决当前合并。