Imagine that you just made and committed a new feature, and are halfway through your next super awesome feature when catastrophe strikes! There’s something wrong with your previous feature that was just committed! What do you do with your current uncommitted work? You could shelve it, you could create a separate repository, or you could simply carry on and make note of the problem, promising to fix it later. You have numerous options.
Let me introduce you to another option: “Mercurial Patch Queues!” he shouted with unmatched enthusiasm.
If you had done this local work as patches instead of commits, you could turn your unfinished working directory changes into a new patch, pop it off the applied stack (out of the working directory), fix your previous patch, re-apply the working directory patch, and then carry on with the work you were in the middle off. Since you modified the patch itself, it’s as if your work was extra perfect the first time around.
In general, making use of these patches will allow you greater control over your changeset history. You can think of it as a private mutable history that you’re free to manipulate however you like before you transform it into the normal shareable state. Allowing you to get your changes just right before committing them, but still giving you advantages of source control.
Another use-case would be temporary “checkpoints”. Let’s say you’re coding, and you want to save your current state, to protect yourself from future blunders, but this effort isn’t done yet and you don’t want to pollute the changeset history with numerous commits. You want one commit that contains all of your related work. For this, you can create a patch of the working directory. If you’ve made a patch, and then later screw up, you can revert your code to the patch, just like you would a previous changeset. So if you screw up later, you can revert to the patch that was made and try again.
Enabling the Extension:
In your mercurial preferences file: add
[extensions] hgext.mq =
And then check it’s working with “hg help mq”
C:UsersmurchDesktopNew folder>hg help mq mq extension - manage a stack of patches This extension lets you work with...
Creating a Repository With a Patch Queue – “hg init –mq”:
- hg init (if it’s already a repository, skip to step 2)
- hg init –mq (Two dashes. Enables the patch queue functionality in the given repository)
Creating a New Patch – “qnew”:
- hg qnew patchname.patch
Update the Patch With Your Work – “qrefresh”:
After making some changes in your working directory, you can use qrefresh to update the topmost patch so that it represents all of your changes.
Note: If your change includes things such as adding a file, you still use the same “hg add” command and then you would use “qrefresh”, so that the change in the patch is “add this file with these contents”.
If you want to apply the changes to a patch that isn’t the topmost patch, you can simply make use of qpush and qpop until the desired patch is at the top of the applied patch stack, and then use qrefresh.
Note: Try to rearrange the patch stack before you make your local changes, otherwise when you go to rearrange with qpop and qpush, you’ll get a message like so: “abort: local changes found, refresh first”. You can force the operation with the -f flag, if you really need to.
Manipulate the Patch Stack – “qpop” and “qpush”:
When working on multiple simultaneous patches, these allow you to manipulate the currently applied patches in your working directory: qpop takes the latest applied patch out of the working directory, and qpush will apply the most recently popped patch back into the working directory.
Make use of the -a flag to push or pop all patches.
Delete an Unwanted Patch – “qdelete”:
You can use qdelete to delete an unwanted patch by name.
Convert a Patch Into a Normal Mercurial Changeset – “qfinish”:
You can use qfinish to convert an applied patch into a normal revision in the changeset history.
Convert a Changeset Into a Patch – “qimport”:
The exact opposite of applying a patch to the changeset history is to take a specified revision and convert it into a patch. You can do this with qimport.
Note: You can only do this if Mercurial considers the changeset to be mutable. Which more or less means you haven’t sent that changeset off anywhere, such as with a push.
Sources and Further Reading:
(HG Book – Managing Change with Mercurial Queues) http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html
(Why would I want to use MQ?) http://mercurial.selenic.com/wiki/MqTutorial#Why_would_I_want_to_use_mq.3F