`qrefresh`被认为有害吗？

Question

扩展中的qrefresh命令MQ对我没有意义.我会解释我的假设:

1. 如果您不知道某个修补程序应该应用于哪个修订版,则它的价值非常小.理论上你无法知道拒绝意味着什么.即使某个修订版本没有拒绝,您也不确定整个修订版本是否会编译.
2. 一旦你qrefresh在你的补丁队列某补丁,你实际上失去在队列中的下一个补丁的父.因此,如果没有您的干预,下一个补丁可能是无用的.
3. 为了修复下一个补丁,你最好合并它而不是手工编辑.rej文件.不仅仅是因为更好的工具,如果你有原始的未qrefresh修补补丁,你有更多的信息,qrefresh导致你丢失实际需要的信息,以使你对补丁的改变有意义.

因此我不明白为什么人们会想要使用这个命令.

更好的选择是,将所有补丁应用hg update到要更改的补丁的父级,然后hg revert将工作目录应用于要更改的补丁.更改此修补程序,将其提交到新修订版,然后重新绑定此新修订版上的所有其他修补程序.

qrefresh当您不编辑单个补丁时,我根本不明白何时相关.似乎这种git方法(将补丁应用于本地分支)比补丁队列更有意义.

我是否正确,我最好使用rebase？我错过了什么吗？

由于没有回复和低视图率而从kiln.se.com迁移

Answer 1

编辑：在写完下面的答案后，我偶然发现了有关Mercurial The Definitive Guide补丁的章节。它说的或多或少相同，但比我的答案更详细。它还建议了一种使用 3 路合并补丁的方法（对我来说有点复杂，但无论如何），就像 OP 正在寻找的那样。

也许您只将 mq 视为补丁导入工具？这不是我的主要用途，对我来说 qrefresh 非常有用。对我来说，典型的用例是当我在已发布的存储库之上工作时。

我通常会同时编写一系列补丁。我首先创建一个新的空补丁。当我相信某些（部分）功能已完成时，我会添加qrefresh顶部补丁以使其包含补丁创建时间（或最后一次qrefresh）所做的所有更改。然后我创建一个新的空补丁并继续编写属于下一个补丁的代码。

如果稍后在处理另一个补丁时我看到应该在先前的补丁中进行一些更改（因为它逻辑上属于它），我不会在顶部补丁中进行更改，也不会创建新的补丁。首先是qrefresh当前补丁，然后qpop是更改所属的上一个补丁，然后进行更改。完成后，我qrefresh再次使用旧补丁，然后qpush回到我正在工作的地方，依此类推。

当你以这种方式工作时，合并通常非常容易，而且我几乎没有遇到任何qpop拒绝qpush。

当我相信我的完整补丁系列已准备好发布时，我会发布qfinish整个系列，并从新的空补丁堆栈开始。

可以使用 rebase 做同样的事情，但是你需要像 git 交互式 rebase 这样的功能。

使用补丁的重点是补丁尚未提交，因此可以轻松更改，为此您需要qrefresh. 好吧，我可以通过创建新补丁并编译它们来实现相同的结果qfold，但这样做确实没有意义，只需两个命令而不是一个命令。

现在，当补丁是外部贡献时，作为我的项目贡献的主要维护者，贡献者包含在贡献者提供的补丁中，并且它们永远不会直接进入存储库。他们首先进入我的主补丁堆栈。如果他们对我正在处理的程序的相同部分进行更改，他们可能会导致拒绝（如果是这样，我基本上根本不插入它，这可能会造成严重破坏）。如果它们应用于当前未更改的程序的其他部分，则它们基本上可以毫无问题地合并，并且可以在补丁堆栈中的任何点导入，没有义务在特定修订中插入它们。但我总是阅读更改，并且经常稍微更改贡献的代码。然后我再次使用 qrefresh 将外部补丁更新为我认为应该的样子。