Is `qrefresh` considered harmful?_问答_开发者_运维开发者技术经验分享

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

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.
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.
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.

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.

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.

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

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.

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.

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.

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.

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

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.

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

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.

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.

You should pick kriss's answer, s/he explains it all very well, but here's a paper about the software that inspired the patch management feature in both mercurial and git, quilt:

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