`qrefresh` 被认为有害吗？
MQ 扩展中的 qrefresh 命令对我来说没有意义。我将解释我的假设：
- 如果您不知道应该在哪个版本上应用某个补丁，那么它的价值就很小。你只是理论上无法知道拒绝意味着什么。即使某个修订版没有被拒绝，您也不确定整个修订版是否可以编译。
- 一旦
qrefresh补丁队列中的某个补丁，您实际上会丢失队列中下一个补丁的父补丁。因此，如果没有您的干预，下一个补丁将/可能毫无用处。 - 为了修复下一个补丁，您最好将其合并，而不是手动编辑
.rej文件。不仅仅是因为更好的工具，如果您有原始的未qrefresh'ed补丁，您将拥有更多信息，qrefresh会导致您丢失实际需要的信息以使您对补丁所做的更改有意义。
因此我不明白为什么有人想要使用这个命令。
更好的选择是，应用所有补丁，然后 hg update 到要更改的补丁的父级，然后，hg revert 将工作目录恢复到您要更改的补丁想要改变。更改此补丁，将其提交到新修订版，然后将所有其他补丁重新设置在此新修订版上。
我根本不明白当您不只编辑单个补丁时 qrefresh 何时相关。看来 git 的方法（将补丁应用到本地分支）比补丁队列更有意义。
我是对的吗？我最好使用 rebase 吗？有什么我错过的吗？
从 kiln.se.com 迁移，因为没有反应和观看率低
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
qrefresha 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, theqrefreshcaused 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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
也许您只将 mq 视为补丁导入工具？这不是我的主要用途，对我来说 qrefresh 非常有用。对我来说，典型的用例是当我在已发布的存储库之上工作时。
我通常会同时编写一系列补丁。我首先创建一个新的空补丁。当我相信某些（部分）功能已完成时，我
qrefresh顶部补丁，使其包含补丁创建时（或上次qrefresh）所做的所有更改。然后我创建一个新的空补丁并继续编写属于下一个补丁的代码。如果稍后在处理另一个补丁时我看到应该在先前的补丁中进行一些更改（因为它逻辑上属于它），我不会在顶部补丁中进行更改，也不会创建新的补丁。首先，我
qrefresh当前补丁，然后qpop到更改所属的上一个补丁，然后进行更改。完成后，我再次qrefresh旧补丁，然后qpush回到我正在工作的地方，依此类推。当您以这种方式工作时，合并通常非常容易，而且我几乎没有遇到拒绝 qpop 和 qpush 的情况。
当我相信我的完整补丁系列已准备好发布时，我
qfinish整个系列，并重新开始一个新的空补丁堆栈。可以使用 rebase 做同样的事情，但是你需要像 git Interactive rebase 这样的功能。
使用补丁的要点在于补丁尚未提交，因此可以轻松更改，为此您需要
qrefresh。好吧，我可以通过创建新补丁并对其进行 qfold 来实现相同的结果，但这样做确实没有意义，只需两个命令而不是一个命令。现在，当补丁是外部贡献时，作为我的项目贡献的主要维护者，贡献者包含在贡献者提供的补丁中，并且它们永远不会直接进入存储库。他们首先进入我的主补丁堆栈。如果他们对我正在处理的程序的相同部分进行更改，他们可能会导致拒绝（如果是这样，我基本上根本不插入它，这可能会造成严重破坏）。如果它们应用于当前未更改的程序的其他部分，则它们基本上可以毫无问题地合并，并且可以在补丁堆栈中的任何点导入，没有义务在特定修订中插入它们。但我总是阅读更改，并且经常稍微更改贡献的代码。然后我再次使用 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.
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
qrefreshthe top patch to make it include all changes made from patch creation time (or lastqrefresh). 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
qrefreshthe current patch, thenqpopto the previous patch where the changes belong, then make my changes. When it's done Iqrefreshagain the old patch, thenqpushback 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 andqpushing around.When I belive my full patch series is ready to be published, I
qfinishthe 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 andqfolding 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.
你应该选择 kriss 的答案，他/她解释得很好，但这里有一篇关于软件的论文，该软件激发了 Mercurial 和 git 中的补丁管理功能，被子：
http://www.suse.de/~agruen/quilt.pdf
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