Mercurial 重新设置基础后修补程序损坏或丢失

我刚刚丢失了Mercurial补丁中的所有更改幸运的是，我有一个备份，我想找出哪里出了问题

设置 我有一对补丁，分别叫patch1.diff和patch2.diff。它们都基于第123版，但影响的文件完全不同，没有重叠。所以，我的存储库在OrtoisehG中看起来像这样，其中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。最终，我不得不运行hgqdelite-keep patch1.diff，然后从异地备份中恢复丢失的更改

我最终到达了我想去的地方，但在一个新功能上几乎失去了几个小时的工作。我之所以能够恢复，只是因为我有一个新文件的异地备份。那太可怕了

问题

---

到底发生了什么事？为什么我丢失了patch1.diff？考虑到我使用hg strip的方式，如果我丢失了patch2.diff中的更改，我可以理解，但我不知道patch1.diff为什么会被禁用。

您在为什么mq可能很快就不再被推荐的问题上遇到了问题。它希望保留对它控制的CSET的控制，当您在mq控制下修改历史记录时，它会失去控制。因此mq不能很好地与rebase、strip、histedit一起工作

更好的方法是完全停止使用mq。将新提交的默认阶段设为机密或草稿。将您的补丁提交为正常的变更集-那么mq就无法干扰rebase的正常工作，您所做的尝试只会起作用。 hg rebase-s125-d123 hg rebase-s124-d126 考虑到您的回购协议在第一个报价中的状态，仅测量r124、r125是正常的CSET，不受mq控制

如果你有点胆识的话，可以看看evolve扩展，它对于维护上游回购的补丁队列或与合作者处理草稿变更集的人非常有用。 有关mercurial阶段的介绍，请参见