On Thu, Mar 13, 2014 at 07:01:37PM -0700, Kevin J. McCarthy wrote: > Kevin J. McCarthy wrote: > > Looking at http://mercurial.selenic.com/wiki/RebaseExtension, there is a > > note about its interaction with mq. It claims it will qfinish and > > qimport any applied mq patches as part of the rebase. I haven't tried > > it, but that doesn't sound like it will leave those patches as mq > > patches when it's done. > > Sorry I didn't look closely enough at the description for qimport (which > *reimports* the patch back into the mq series). So I guess the rebase > will leave it as an mq patch. Since I haven't played with this, I'll > stop making unhelpful comments now :-/
That's cool, I appreciate your follow up. Here's what a developer I work with had to say when I asked him about hg pull --rebase: Will Fiveash wrote: > If I have a hg repo with a set of mq patches and I use: > > $ hg pull --rebase > > to update my repo with changesets from the parent repo will this rebase > my local mq patches and leave them as mq patches? Yes, that'll work just fine. > If so, do I need to "hg qpush -a" all my patches before doing the "hg > pull --rebase"? You don't have to, but any patches you have that aren't applied and don't apply after the pull will have to be fixed "manually", just as if you did a qpop -a/pull -u/qpush cycle -- it won't benefit from any of the built-in merge assistance that you get with rebase. I don't bother rebasing all of my patches, since a) many of them are really old and it'd just be a lot of work for work I don't really want to page in just now, and b) I'm usually working in a non-ON repo, where things are pretty independent. But if I had to do that, I might pop everything off the queue, update to the last changeset where I applied it (or I thought it'd apply cleanly), qpush --move the patch in question, and then rebase the mq changeset. That should give you the same machinery, but in a lazy fashion. I haven't tried it, though, so if you do, do it on a throwaway clone. :) -- Will Fiveash
