【问题标题】：Patch corruption or loss after rebase变基后补丁损坏或丢失
【发布时间】：2014-12-03 05:22:13
【问题描述】：

我刚刚丢失了 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 会遭到破坏。

【问题讨论】：

标签： mercurial patch tortoisehg

【解决方案1】：

您偶然发现了 mq 可能很快不再被推荐的问题。它希望保留对其控制的 cset 的控制权，但当您在 mq 控制下修改历史记录时，它会失去控制权。因此 mq 不适用于 rebase、strip、histedit...

更好的方法是完全停止使用 mq。将新提交的默认阶段设为机密（或草稿）。将您的补丁作为普通变更集提交 - 然后 mq 无法干扰 rebase 的正常工作，而您所做的尝试只会奏效。 hg rebase -s125 -d123 hg rebase -s124 -d126 （鉴于您的回购状态如第一个报价所示，假设 r124、r125 是正常的 cset，不受 mq 控制）

如果你有一点胆量，你可以看看 Evolution 扩展，它对于维护上游 repos 的补丁队列或与合作者处理草稿变更集的人非常有用。请参阅http://www.logilab.org/blogentry/88203 了解汞相的介绍

【讨论】：