我刚刚丢失了Mercurial补丁中的所有更改（幸运的是，我有一个备份），我想弄清楚出了什么问题。
我有一对补丁，称之为patch1.diff和patch2.diff。它们都基于修订版123，但影响完全不同的文件，没有重叠。所以，我的存储库在TortoiseHg中看起来像这样（其中p是补丁而r是常规修订版）：
Graph Rev Branch Tags Message
p 125 develop patch2.diff Change to existing file baz.php
p 124 develop patch1.diff Add new files foo.php and bar.php
r 123 develop Last committed changeset
|
r 122 develop Old changes
...
我想切换补丁的顺序，因为我对patch2.diff的工作已经完成，我想提交这些更改。所以我尝试将该补丁修改为修订版123.这没有用，我最终得到了类似的东西：
Graph Rev Branch Tags Message
r Working directory - not a head revision!
r 126 develop Change to existing file baz.php
|
p | 125 develop patch2.diff Change to existing file baz.php
|
p | 124 develop patch1.diff Add new files foo.php and bar.php
|
r-+ 123 develop Last committed changeset
|
r 122 develop Old changes
...
这显然是错的。我现在有一个版本126与patch2.diff中的修改相同，但我还有一个patch2.diff，它没有像我预期的那样重新设置。最重要的是，即使我的工作目录中没有任何变化，我也收到了“非头部修订”的消息。
所以我删除了修订版126.那时，事情完全脱离了轨道，让我这样：
Graph Rev Branch Tags Message
p 125 develop patch2.diff Change to existing file baz.php
p 124 develop patch1.diff
r 123 develop Last committed changeset
|
r 122 develop Old changes
...
patch1.diff仍然出现在TortoiseHg中，但更改和提交消息都消失了。我尝试了hg qpush --all，并收到了以下消息：
applying patch1.diff
unable to read patch1.diff
我甚至无法在我的文件系统上找到patch1.diff。最终，我必须运行hg qdelete --keep patch1.diff，然后从异地备份中恢复丢失的更改。
我最终到达了我想去的地方，但几乎失去了一个新功能的工作时间。我之所以能恢复只是因为我有新文件的异地备份。那太可怕了。
世界上发生了什么？为什么我会丢失patch1.diff？我可以理解，如果我使用hg strip的方式丢失了patch2.diff中的更改，但我不知道为什么patch1.diff会被修改。
答案 0 :(得分：2)
你偶然发现了为什么mq可能很快就不会被推荐了。当你在mq控制下修改历史时，它希望保持对它控制的cset的控制，并且它会失去控制。因此mq不适用于rebase，strip，histedit ......
更好的方法是根本停止使用mq。使新提交的默认阶段为秘密（或草稿）。将您的补丁作为正常的变更集提交 - 然后mq不会干扰rebase的正常工作，并且您尝试做的事情只会起作用。 hg rebase -s125 -d123 hg rebase -s124 -d126 （鉴于你的回购状态如第一个引用，只是asusming r124，r125是正常cset，而不是mq控制）
如果你有点大胆，你可以看一下evolve扩展，这对于那些维护上游repos或与协作者一起调整草案变更集的补丁队列非常有用。 有关mercurial阶段的介绍，请参阅http://www.logilab.org/blogentry/88203