qrefresh扩展程序中的MQ命令对我没有意义。我会解释我的假设：
qrefresh某个补丁后，您实际上正在丢失队列中下一个补丁的父级。因此，如果没有您的干预，下一个补丁可能是无用的。.rej个文件。不仅仅是因为有更好的工具，如果你有原始的非qrefresh'补丁，你有更多的信息，qrefresh会导致你丢失实际需要的信息，以便你做出改变对补丁有意义。因此我不明白为什么人们会想要使用这个命令。
更好的选择是，将所有修补程序，然后hg update应用于要更改的修补程序的父项，然后hg revert将工作目录应用于要更改的修补程序。更改此修补程序，将其提交到新修订版，然后重新绑定此新修订版上的所有其他修补程序。
当您不编辑单个补丁时，我根本不明白qrefresh何时相关。似乎git的方法（将补丁应用于本地分支）比补丁队列更有意义。
我是否正确，我最好使用rebase？有没有我错过的东西？
由于没有回应和低观看率而从kiln.se.com迁移
答案 0 :(得分：3)
编辑：写完下面的答案后，我偶然发现了chapter about patches Mercurial The 权威指南。它说更多或 不太相同，但更多 详细说明我的答案。它也是 提出一种方式（对我来说有点复杂） 味道，但无论如何）使用3路合并 OP正在寻找补丁 对
也许你只看到mq作为补丁导入工具？这不是我的主要用途，对我来说qrefresh非常有用。对我来说，典型的用例是当我在已发布的存储库顶部工作时。
我经常使用一系列我正在同时写的补丁。我首先创建一个新的空补丁。当我相信一些（部分）功能完成时，我qrefresh顶部补丁使其包含从补丁创建时间（或最后qrefresh）所做的所有更改。然后我创建一个新的空补丁并继续编写属于下一个补丁的代码。
如果稍后在处理另一个补丁时我发现应该在之前的补丁中进行一些更改（因为它在逻辑上属于它），我不会在顶部补丁中进行更改，也不会创建新补丁。首先我qrefresh当前的补丁，然后qpop到更改所属的上一个补丁，然后进行我的更改。完成后我再次qrefresh旧补丁，然后qpush回到我工作的地方，依此类推。
当你以这种方式工作时，合并通常很容易，我几乎没有拒绝qpop和qpush。
当我相信我的完整补丁系列已准备好发布时，我qfinish整个系列，然后重新开始使用新的空补丁堆栈。
使用rebase可以做同样的事情，但是你需要像git interactive rebase这样的功能。
关于使用补丁的重点是补丁尚未提交，因此可以轻松更改，为此您需要qrefresh。好吧，我可以在创建新补丁和qfold时获得相同的结果，但实际上没有必要这样做，只需要两个命令而不是一个。
现在，当补丁是外部贡献时，作为我的项目贡献的主要维护者包含在贡献者提供的补丁中，他们永远不会直接进入存储库。他们首先进入我的主要补丁堆栈。如果他们对我正在进行的程序的相同部分进行更改，他们可能会导致拒绝（如果是这样，我基本上不会插入它，它可能会造成严重破坏）。如果它们适用于当前未更改的程序的某些其他部分，它们基本上合并没有任何问题，可以在补丁堆栈中的任何点导入，没有义务将它们插入特定修订。但我总是阅读这些更改，而且我经常略微更改提供的代码。然后我再次使用qrefresh将外部补丁更新为我应该相信的内容。
答案 1 :(得分：0)
你应该选择kriss的答案，他/她解释得非常好，但是这里有一篇关于软件的论文，它启发了mercurial和git中的补丁管理功能，被子：