5

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

  1. 如果您不知道应该在哪个版本上应用某个补丁，那么它的价值就很小。从理论上讲，您无法知道拒绝是什么意思。即使某个版本没有被拒绝，您也不确定整个版本是否会编译。
  2. 一旦你qrefresh在你的补丁队列中找到了某个补丁，你实际上就失去了队列中下一个补丁的父级。所以如果没有你的干预，下一个补丁是/可能是无用的。
  3. 为了修复下一个补丁，您最好合并它而不是手动编辑.rej文件。不仅仅是因为更好的工具，如果你有原始的未qrefresh编辑补丁，你就会有更多的信息，这会qrefresh导致你丢失你真正需要的信息，以便使你对补丁所做的更改有意义。

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

更好的选择是，应用所有补丁，然后应用hg update到要更改的补丁的父级，然后hg revert将工作目录应用到要更改的补丁。更改此补丁，将其提交到新修订版，然后在此新修订版上重新定位所有其他补丁。

qrefresh当您不只编辑单个补丁时，我根本不明白何时相关。似乎这种git方法（将补丁应用到本地分支）比补丁队列更有意义。

我是否正确，我最好使用变基？有什么我错过的吗？

因无反应且浏览量低，从窑炉网迁移

4

2 回答 2

3

编辑：在写完下面的答案后，我偶然发现了关于Mercurial The Definitive Guide补丁的章节。它说的差不多，但比我的回答要详细得多。它还提出了一种方法（根据我的口味，有点令人费解，但无论如何）使用 OP 正在寻找的补丁的 3 路合并。

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

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

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

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

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

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

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

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

于 2010-11-09T13:12:41.097 回答
0

您应该选择 kriss 的答案，他/她解释得很好，但这里有一篇关于激发 mercurial 和 git 中的补丁管理功能的软件的论文，被子：

http://www.suse.de/~agruen/quilt.pdf

于 2010-11-09T14:36:25.500 回答