Mercurial_ The Definitive Guide - Bryan O'Sullivan [98]
Use hg pull to bring new changes into the underlying repository. (Don’t run hg pull -u; see below for why.)
Update to the new tip revision, using hg update -C to override the patches you have pushed.
Merge all patches using hg qpush -m -a. The -m option to qpush tells MQ to perform a three-way merge if the patch fails to apply.
During the hg qpush hg -m, each patch in the series file is applied normally. If a patch applies with fuzz or rejects, MQ looks at the queue you qsaved, and performs a three-way merge with the corresponding changeset. This merge uses Mercurial’s normal merge machinery, so it may pop up a GUI merge tool to help you to resolve problems.
When you finish resolving the effects of a patch, MQ refreshes your patch based on the result of the merge.
At the end of this process, your repository will have one extra head from the old patch queue, and a copy of the old patch queue will be in .hg/patches.N. You can remove the extra head using hg qpop -a -n patches.N or hg strip. You can delete .hg/patches.N once you are sure that you no longer need it as a backup.
Identifying Patches
MQ commands that work with patches let you refer to a patch either by using its name or by a number. By name is obvious enough; pass the name foo.patch to qpush, for example, and it will push patches until foo.patch is applied.
As a shortcut, you can refer to a patch using both a name and a numeric offset; foo.patch-2 means “two patches before foo.patch”, while bar.patch+4 means “four patches after bar.patch”.
Referring to a patch by index isn’t much different. The first patch printed in the output of qseries is patch zero (yes, it’s one of those start-at-zero counting systems); the second is patch one; and so on.
MQ also makes it easy to work with patches when you are using normal Mercurial commands. Every command that accepts a changeset ID will also accept the name of an applied patch. MQ augments the tags normally in the repository with an eponymous one for each applied patch. In addition, the special tags qbase and qtip identify the bottom-most and topmost applied patches, respectively.
These additions to Mercurial’s normal tagging capabilities make dealing with patches even more of a breeze.
Want to patchbomb a mailing list with your latest series of changes?hg email qbase:qtip
(Don’t know what “patchbombing” is? See Sending Changes via Email with the patchbomb Extension.)
Need to see all of the patches since foo.patch that have touched files in a subdirectory of your tree?hg log -r foo.patch:qtip subdir
Because MQ makes the names of patches available to the rest of Mercurial through its normal internal tag machinery, you don’t need to type in the entire name of a patch when you want to identify it by name.
Another nice consequence of representing patch names as tags is that when you run the hg log command, it will display a patch’s name as a tag, simply as part of its normal output. This makes it easy to visually distinguish applied patches from underlying “normal” revisions. The following example shows a few normal Mercurial commands in use with applied patches.
$ hg qapplied
first.patch
second.patch
$ hg log -r qbase:qtip
changeset: 1:c88942a2377a
tag: first.patch
tag: qbase
user: Bryan O'Sullivan date: Tue May 05 06:44:40 2009 +0000 summary: [mq]: first.patch changeset: 2:1934c63ed3c5 tag: qtip tag: second.patch tag: tip user: Bryan O'Sullivan date: Tue May 05 06:44:41 2009 +0000 summary: [mq]: second.patch $ hg export second.patch # HG changeset patch # User Bryan O'Sullivan # Date 1241505881 0 # Node ID 1934c63ed3c5ddf96f80bd5b965a15edbb2251a9 # Parent c88942a2377a5d6d177ace3bea3e74cf653de8a3 [mq]: