qrefresh是否被认为有害? [英] Is `qrefresh` considered harmful?

问题描述

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

The qrefresh command in the MQ extension don't make sense to me. I'll explain my assumption:

1. 如果您不知道应该在哪个修订版上应用某个补丁，那么它的价值将很小.从理论上讲，您只是不知道拒绝是什么意思.而且即使某个版本没有拒绝，您也不确定整个版本是否可以编译.
2. 一旦您qrefresh修补程序队列中的某个修补程序，实际上就失去了队列中下一个修补程序的父级.因此，在没有您的干预的情况下，下一个补丁可能是无用的.
3. 为了修复下一个补丁，最好将其合并，而不是手工编辑.rej文件.不仅仅是因为使用了更好的工具，如果您拥有原始的未qrefresh版本的补丁，您还将获得更多信息，qrefresh导致您丢失了实际需要的信息，以便对补丁进行更改.有意义的.

1. If you don't know on which revision should a certain patch be applied, it have a very little value. You just can't theoretically know what does the rejects mean. And even if there are no rejects on a certain revision, you're not sure the whole revision would compile.
2. Once you qrefresh a certain patch in your patch queue, you're actually losing the parent of the next patch in the queue. So that without your intervention this next patch is/might be useless.
3. In order to fix the next patch, you'd better merge it instead of hand-editing the .rej, files. Not just because of the better tools, if you have the original un-qrefresh'ed patch, you have more information, the qrefresh caused you to lose information you actually need in order to make the change you made to the patch meaningful.

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

Therefor I don't understand why one would ever want to use this command.

一个更好的选择是，先应用所有补丁，然后将hg update应用于要更改的补丁的父目录，然后将hg revert工作目录应用于要更改的补丁.更改此修补程序，将其提交到新修订版本，然后将所有其他修补程序重新基于此新修订版本.

A better alternative is, to apply all the patches, then hg update to the parent of the patch you want to change, then, hg revert the working directory to the patch you want to change. Change this patch, commit it to a new revision, and then rebase all the other patches on this new revision.

当您不只编辑单个补丁时，我根本不理解qrefresh何时有意义.看来git的方法(将补丁应用到本地分支)比补丁队列有意义得多.

I simply don't understand when qrefresh is relevant when you're not editing a single patch only. It seems that git's approach (apply the patch to a local branch) makes much more sense than a patch queue.

我正确了吗，我最好使用rebase吗?有什么我想念的吗?

Am I correct, and I'd better of use rebase? Is there something I missed?

从 kiln.se.com 迁移由于没有响应且收视率低

migrated from kiln.se.com due to no response and low view rate

推荐答案

编辑:在写下下面的答案后，我偶然发现了

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非常有用.对我来说，典型的用例是当我在已发布存储库的顶部工作时.

Maybe you see mq only as a patch import tool ? That is not my primary use, and for me qrefresh is very useful. The typical use case for me is when I'm working over the top of published repository.

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

I usually work with a series of patches I'm writing at the same time. I begin by creating a new empty patch. When I believe some (part of a) feature is finished, I qrefresh the top patch to make it include all changes made from patch creation time (or last qrefresh). Then I create a new empty patch and continue writing code that belong to the next patch.

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

If at a later time when working on another patch I see some change that should be made inside a previous patch (because it logically belongs to it), I do not make the change in the top patch nor create a new patch. First I qrefresh the current patch, then qpop to the previous patch where the changes belong, then make my changes. When it's done I qrefresh again the old patch, then qpush back to where I was working, and so on.

以这种方式工作时，合并通常非常容易，并且qpop ing和qpush ing几乎没有拒绝.

When you work this way, merges are usually very easy and I get nearly no rejects qpoping and qpushing around.

当我相信我准备发布的完整补丁系列时，我会qfinish整个系列，然后从一个新的空补丁栈开始.

When I belive my full patch series is ready to be published, I qfinish the whole series, and start again with a new empty patch stack.

使用rebase可以执行相同的操作，但是您需要git交互式rebase之类的功能.

It is possible to do the same kind of things with rebase, but then you would need feature like git interactive rebase.

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

The whole point about working with patches is that patches are not yet commited, so can easily be changed, and for that you need qrefresh. Well, I could achieve the same result creating new patches and qfolding them, but there would really be not point doing that, just two commands instead of one.

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

Now, when patches are external contributions, as a main maintener to my project contributions are included from patches provided by contributors and they never get directly to the repository. They first get inside my main patch stack. If they make changes to the same parts of program I'm working on they are likely to cause rejects (and if so I basicaly do not insert it at all, it is likely to wreak havoc). If they apply to some other part of the program not being currently changed, they basically merge without any problem an can be imported at any point in the patch stack, no obligation to insert them upon a specific revision. But I always read the changes, and quite often I slightly change the contributed code. Then again I use qrefresh to update the external patch to what I belive it should be.

这篇关于qrefresh是否被认为有害?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！