mercurial - `qrefresh`被认为有害吗？

qrefresh扩展名中的MQ命令对我来说没有意义。我将解释我的假设:

如果您不知道某个补丁程序应该在哪个修订版上应用，那么它的值(value)就很小。从理论上讲，您只是不知道拒绝是什么意思。即使某个版本没有拒绝，您也不确定整个版本是否会编译。

一旦您对补丁程序队列中的某个补丁程序进行了qrefresh编码，实际上就失去了队列中下一个补丁程序的父级。因此，在没有您的干预的情况下，下一个补丁可能是无用的。

为了修复下一个补丁，最好将其合并，而不是手工编辑.rej文件。不仅仅是因为有了更好的工具，如果您拥有原始的unqrefresh补丁，您还将获得更多信息，而qrefresh则使您失去了实际需要的信息，从而使对补丁所做的更改有意义。

因此，我不明白为什么要使用此命令。

更好的替代方法是，先应用所有补丁，然后将hg update应用于要更改的补丁的父目录，然后将工作目录hg revert应用于要更改的补丁。更改此修补程序，将其提交到新修订版，然后将所有其他修补程序重新建立在该新修订版的基础上。

当您不只编辑单个修补程序时，我根本不了解qrefresh是否相关。看来git的方法(将补丁应用到本地分支)比补丁队列有意义得多。

我是正确的，并且我最好使用rebase吗？有什么我想念的吗？

由于无响应和观看率低而从kiln.se.com迁移

最佳答案

也许您仅将mq视为修补程序导入工具？那不是我的主要用途，对我来说qrefresh非常有用。对我来说，典型的用例是当我处理已发布存储库的顶部时。

我通常会同时处理一系列补丁。我首先创建一个新的空补丁。当我相信某些功能(一部分)完成时，我qrefresh最上面的补丁程序，使其包括对补丁程序创建时间(或最后qrefresh)所做的所有更改。然后，我创建一个新的空补丁，并继续编写属于下一个补丁的代码。

如果以后在处理另一个修补程序时，我发现应该在先前的修补程序中进行某些更改(因为它在逻辑上属于该修补程序)，那么我不会在顶部修补程序中进行更改，也不会创建新的修补程序。首先，我qrefresh当前补丁，然后qpop到更改所属的前一个补丁，然后进行更改。完成后，我再次qrefresh旧补丁，然后qpush返回我的工作位置，依此类推。

当您以这种方式工作时，合并通常非常容易，而且我得到的qpop和qpush几乎没有拒绝。

当我相信我的完整补丁系列准备发布时，我对整个系列进行qfinish编码，然后从一个新的空补丁堆栈开始。

可以使用rebase进行相同的操作，但随后您将需要git交互式rebase之类的功能。

使用补丁的全部要点是尚未提交补丁，因此可以轻松更改，因此需要qrefresh。好吧，我可以通过创建新补丁并对其进行qfold来获得相同的结果，但是这样做并没有意义，只有两个命令而不是一个。

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

关于mercurial - `qrefresh`被认为有害吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4133123/