0

我对主（也是唯一的）分支进行了一些更改（A）。然后我的同事做了一些其他的改变（B）。然后我发现更改（A）被彻底破坏了，我决定完全放弃它们。另一方面，变化 (B) 非常好，幸运的是完全独立于变化 (A)。变化（B）的数量远小于变化（A）。

通常，我会hg commit --close-branch按照这里的描述进行。但是后来我丢失了更改（B），并且需要在新的活动分支中重新创建它们。我可以做到这一点，只需（手动）识别受影响的文件，并（手动）更新它们，然后提交。这显然不是完美的，因为它需要两个手动步骤，并且还在存储库中创建了一个误导性的提交（误导性是因为这些更改是我的同事不久前做出的，但看起来好像是我今天做出的）。我想这不是世界末日，但有更优雅的解决方案吗？

注意：如果 Mercurial 支持仅将一个提交的差异应用到修订树中的另一个位置，它就会起作用。但我怀疑此功能不存在，这是有充分理由的：当逐字应用于另一个父变更集时，差异与现有父变更集非常有用。

4

1 回答 1

4
  1. --close-branch有另一个理由，而不是丢弃坏的变更集
  2. 您可以通过提供“undoing-changeset”来撤消早期历史中出现的任何更改集，读取hg help backout，在常见的hg backout CSET-HASH反向更改中，在 CSET-HASH 中完成，以支付在 repo 中额外提交的成本

使用回退来杀死旧变更集的示例（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
  1. 您可以在分支之间挑选变更集，读取hg help graft（基于合并的注入逻辑而不是 old hg transplant）。有用性或无用性是人类选择的问题，移植变更集在新父级之上的可操作性（无合并冲突）是移植本身的责任

如果嫁接合并导致冲突，则中断嫁接过程，以便可以手动解决当前合并。

于 2012-12-02T06:02:09.713 回答