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

Question

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

1. 如果您不知道某个补丁应该应用在哪个版本上，那么它的值(value)就很小。你只是理论上无法知道拒绝意味着什么。即使某个修订版没有被拒绝，您也不确定整个修订版能否编译。
2. qrefresh 补丁队列中的某个补丁后，您实际上会丢失队列中下一个补丁的父补丁。因此，如果没有您的干预，下一个补丁将/可能毫无用处。
3. 为了修复下一个补丁，您最好将其 merge ，而不是手动编辑 .rej 文件。不仅仅是因为更好的工具，如果您有原始的未qrefresh'ed补丁，您将拥有更多信息，qrefresh会导致您丢失实际需要的信息以使您对补丁所做的更改有意义。

因此我不明白为什么有人想要使用这个命令。

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

我根本不明白当您不只编辑单个补丁时 qrefresh 何时相关。看来 git 的方法(将补丁应用到本地分支)比补丁队列更有意义。

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

迁移自 kiln.se.com由于没有回复且观看率低

Answer 1

EDIT: after writing the answer below, I stumbled upon the chapter about patches of Mercurial The Definitive Guide. It says more or less the same but is much more detailed that my answer. It also suggest a way (a bit convoluted for my taste, but anyway) to use 3-way merge with patches as the OP was looking for.

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

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

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

当您以这种方式工作时， merge 通常非常容易，并且我几乎不会拒绝 qpoping 和 qpushing。

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

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

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

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