In Mercurial, is it "safe" to pull when an mq patch is applied?

Question

The go programming language contains a page for viewing code using mq, and it reads: "Since pulling, pushing, updating and fixing during mq patches can damage your repository."

I understand why clicking or updating may be a problem, but causing a problem?

If you have mq fixes and you pull, will your repository get corrupted?

Answer 1

This, of course, can be a problem if you accidentally merged with the advanced changesets while you have the MQ fixes applied in your repository. Here's the script I just tried that seems to be causing problems:

• suppose in your clone you click all your patches with hg qpush -a
• then you pull revisions from the upstream using hg pull (but not hg update ). this creates a new branch ( hg heads shows the branch you are on as qtip and the new branch you just pulled as tip )
• when you hack, you decide to switch to a new branch and run hg update -C tip , but do this without selecting your patches.
• when you crack some more, you decide to merge branches with hg merge . Unfortunately! You just merged in an MQ patch that was never qfinished .

Since MQ works by creating and destroying a story, patch changes look like normal parts of a story. However, since you “jumped” on the application patches and combined them with a set of patches without patches, you can no longer drop patches. In fact, hg qpop is hg qpop by a message:

 abort: popping would remove a revision not managed by this patch queue 

Usually I just try to be careful and conscious in pulling or pushing when I work with the patch queue, but the hooks offered on the go page provide good protection.

Note that you can always reinstall your fixes on top of the top change sets. See this page for a description of how to do this.

Answer 2

If you have mq fixes and you pull, will your repository get corrupted?

The answer is no . When you pull, you add more changes to your local history. The attached MQ fixes are also displayed as change sets on the change set schedule, but this is not dangerous and you will not lose any data.

What could happen is that you applied some fixes:

 .... a --- b --- p1 --- p2 --- p3 

You then send the fixes to the mailing list upstream for inclusion. Someone looks at patches, commits them and puts the changes into the main repository. Other changes will be pushed later, and the next time you pull, you will get:

 .... a --- b --- p1 --- p2 --- p3 --- c --- d 

Changes p1 to p3 are still MQ plugins in your repository, but now they have children without MQ! Attempting to pull them leads to (with Mercurial 2.1.1):

 $ hg qpop abort: popping would remove a revision not managed by this patch queue 

This is a little dead castle. It is annoying, but not dangerous. To resolve this, you must make MQ understandable that p1 to p3 no longer controlled by MQ. You do this by deleting lines for these change sets with .hg/patches/status . MQ is likely to end up deleting these lines on its own when it happens, but it happens quite rarely, so no one has written this patch yet.