hgbook
diff en/ch12-mq.xml @ 559:b90b024729f1
WIP DocBook snapshot that all compiles. Mirabile dictu!
| author | Bryan O'Sullivan <bos@serpentine.com> |
|---|---|
| date | Wed Feb 18 00:22:09 2009 -0800 (2009-02-18) |
| parents | 8631da51309b |
| children | 8fcd44708f41 |
line diff
1.1 --- a/en/ch12-mq.xml Mon Feb 09 23:25:40 2009 -0800 1.2 +++ b/en/ch12-mq.xml Wed Feb 18 00:22:09 2009 -0800 1.3 @@ -36,17 +36,17 @@ 1.4 <para>When you have few changes to maintain, it is easy to manage 1.5 a single patch using the standard <command>diff</command> and 1.6 <command>patch</command> programs (see section <xref 1.7 - linkend="sec:mq:patch"/> for a discussion of these tools). 1.8 - Once the number of changes grows, it starts to make sense to 1.9 - maintain patches as discrete <quote>chunks of work,</quote> so 1.10 - that for example a single patch will contain only one bug fix 1.11 - (the patch might modify several files, but it's doing 1.12 - <quote>only one thing</quote>), and you may have a number of 1.13 - such patches for different bugs you need fixed and local changes 1.14 - you require. In this situation, if you submit a bug fix patch 1.15 - to the upstream maintainers of a package and they include your 1.16 - fix in a subsequent release, you can simply drop that single 1.17 - patch when you're updating to the newer release.</para> 1.18 + linkend="sec:mq:patch"/> for a discussion of these 1.19 + tools). Once the number of changes grows, it starts to make 1.20 + sense to maintain patches as discrete <quote>chunks of 1.21 + work,</quote> so that for example a single patch will contain 1.22 + only one bug fix (the patch might modify several files, but it's 1.23 + doing <quote>only one thing</quote>), and you may have a number 1.24 + of such patches for different bugs you need fixed and local 1.25 + changes you require. In this situation, if you submit a bug fix 1.26 + patch to the upstream maintainers of a package and they include 1.27 + your fix in a subsequent release, you can simply drop that 1.28 + single patch when you're updating to the newer release.</para> 1.29 1.30 <para>Maintaining a single patch against an upstream tree is a 1.31 little tedious and error-prone, but not difficult. However, the 1.32 @@ -146,42 +146,42 @@ 1.33 unification of patches and revision control.</para> 1.34 1.35 <para>A major reason that patches have persisted in the free 1.36 - software and open source world&emdash;in spite of the availability of 1.37 - increasingly capable revision control tools over the years&emdash;is 1.38 - the <emphasis>agility</emphasis> they offer.</para> 1.39 + software and open source world&emdash;in spite of the 1.40 + availability of increasingly capable revision control tools over 1.41 + the years&emdash;is the <emphasis>agility</emphasis> they 1.42 + offer.</para> 1.43 1.44 <para>Traditional revision control tools make a permanent, 1.45 irreversible record of everything that you do. While this has 1.46 great value, it's also somewhat stifling. If you want to 1.47 perform a wild-eyed experiment, you have to be careful in how 1.48 you go about it, or you risk leaving unneeded&emdash;or worse, 1.49 - misleading or destabilising&emdash;traces of your missteps and errors 1.50 - in the permanent revision record.</para> 1.51 + misleading or destabilising&emdash;traces of your missteps and 1.52 + errors in the permanent revision record.</para> 1.53 1.54 <para>By contrast, MQ's marriage of distributed revision control 1.55 with patches makes it much easier to isolate your work. Your 1.56 patches live on top of normal revision history, and you can make 1.57 them disappear or reappear at will. If you don't like a patch, 1.58 you can drop it. If a patch isn't quite as you want it to be, 1.59 - simply fix it&emdash;as many times as you need to, until you have 1.60 - refined it into the form you desire.</para> 1.61 + simply fix it&emdash;as many times as you need to, until you 1.62 + have refined it into the form you desire.</para> 1.63 1.64 <para>As an example, the integration of patches with revision 1.65 control makes understanding patches and debugging their 1.66 effects&emdash;and their interplay with the code they're based 1.67 - on&emdash;<emphasis>enormously</emphasis> easier. Since every applied 1.68 - patch has an associated changeset, you can use <command 1.69 - role="hg-cmd">hg log</command> to see which changesets and 1.70 - patches affected a file. You can use the <literal 1.71 - role="hg-ext">bisect</literal> command to binary-search 1.72 - through all changesets and applied patches to see where a bug 1.73 - got introduced or fixed. You can use the <command 1.74 + on&emdash;<emphasis>enormously</emphasis> easier. Since every 1.75 + applied patch has an associated changeset, you can give <command 1.76 + role="hg-cmd">hg log</command> a file name to see which 1.77 + changesets and patches affected the file. You can use the 1.78 + <command role="hg-cmd">hg bisect</command> command to 1.79 + binary-search through all changesets and applied patches to see 1.80 + where a bug got introduced or fixed. You can use the <command 1.81 role="hg-cmd">hg annotate</command> command to see which 1.82 changeset or patch modified a particular line of a source file. 1.83 And so on.</para> 1.84 1.85 </sect1> 1.86 - 1.87 <sect1 id="sec:mq:patch"> 1.88 <title>Understanding patches</title> 1.89 1.90 @@ -241,7 +241,8 @@ 1.91 1.92 <para>We will return to some of the more subtle aspects of patches 1.93 later (in section <xref linkend="sec:mq:adv-patch"/>), but you 1.94 - should have enough information now to use MQ.</para> 1.95 + should have 1.96 + enough information now to use MQ.</para> 1.97 1.98 </sect1> 1.99 <sect1 id="sec:mq:start"> 1.100 @@ -250,15 +251,16 @@ 1.101 <para>Because MQ is implemented as an extension, you must 1.102 explicitly enable before you can use it. (You don't need to 1.103 download anything; MQ ships with the standard Mercurial 1.104 - distribution.) To enable MQ, edit your <filename role="home"> 1.105 - /.hgrc</filename> file, and add the lines below.</para> 1.106 + distribution.) To enable MQ, edit your <filename 1.107 + role="home">~/.hgrc</filename> file, and add the lines 1.108 + below.</para> 1.109 1.110 <programlisting>[extensions] hgext.mq =</programlisting> 1.111 1.112 <para>Once the extension is enabled, it will make a number of new 1.113 commands available. To verify that the extension is working, 1.114 you can use <command role="hg-cmd">hg help</command> to see if 1.115 - the <command role="hg-ext-mq">hg qinit</command> command is now 1.116 + the <command role="hg-ext-mq">qinit</command> command is now 1.117 available.</para> 1.118 1.119 <!-- &interaction.mq.qinit-help.help; --> 1.120 @@ -266,25 +268,29 @@ 1.121 <para>You can use MQ with <emphasis>any</emphasis> Mercurial 1.122 repository, and its commands only operate within that 1.123 repository. To get started, simply prepare the repository using 1.124 - the <command role="hg-ext-mq">hg qinit</command> command. This 1.125 - command creates an empty directory called <filename 1.126 + the <command role="hg-ext-mq">qinit</command> command.</para> 1.127 + 1.128 +<!-- &interaction.mq.tutorial.qinit; --> 1.129 + 1.130 + <para>This command creates an empty directory called <filename 1.131 role="special" class="directory">.hg/patches</filename>, where 1.132 MQ will keep its metadata. As with many Mercurial commands, the 1.133 - <command role="hg-ext-mq">hg qinit</command> command prints nothing 1.134 + <command role="hg-ext-mq">qinit</command> command prints nothing 1.135 if it succeeds.</para> 1.136 -<!-- &interaction.mq.tutorial.qinit; --> 1.137 - 1.138 1.139 <sect2> 1.140 <title>Creating a new patch</title> 1.141 1.142 <para>To begin work on a new patch, use the <command 1.143 - role="hg-ext-mq">hg qnew</command> command. This command takes 1.144 - one argument, the name of the patch to create. MQ will use 1.145 - this as the name of an actual file in the <filename 1.146 - role="special" class="directory">.hg/patches</filename> 1.147 - directory, as you can see in figure <xref 1.148 - linkend="ex:mq:qnew"/>.</para> 1.149 + role="hg-ext-mq">qnew</command> command. This command takes 1.150 + one argument, the name of the patch to create.</para> 1.151 + 1.152 + <para>MQ will use this as the name of an actual file in the 1.153 + <filename role="special" 1.154 + class="directory">.hg/patches</filename> directory, as you 1.155 + can see below.</para> 1.156 + 1.157 +<!-- &interaction.mq.tutorial.qnew; --> 1.158 1.159 <para>Also newly present in the <filename role="special" 1.160 class="directory">.hg/patches</filename> directory are two 1.161 @@ -318,18 +324,19 @@ 1.162 <title>Refreshing a patch</title> 1.163 1.164 <para>When you reach a point where you want to save your work, 1.165 - use the <command role="hg-ext-mq">hg qrefresh</command> 1.166 - command to update the patch you are working on. This command 1.167 - folds the changes you have made in the working directory into 1.168 - your patch, and updates its corresponding changeset to contain 1.169 - those changes.</para> 1.170 + use the <command role="hg-ext-mq">qrefresh</command> command 1.171 + to update the patch you are working on.</para> 1.172 1.173 <!-- &interaction.mq.tutorial.qrefresh; --> 1.174 1.175 - <para>You can run <command role="hg-ext-mq">hg hg 1.176 - qrefresh</command> as often as you like, so it's a good way 1.177 - to <quote>checkpoint</quote> your work. Refresh your patch at 1.178 - an opportune time; try an experiment; and if the experiment 1.179 + <para>This command folds the changes you have made in the 1.180 + working directory into your patch, and updates its 1.181 + corresponding changeset to contain those changes.</para> 1.182 + 1.183 + <para>You can run <command role="hg-ext-mq">qrefresh</command> 1.184 + as often as you like, so it's a good way to 1.185 + <quote>checkpoint</quote> your work. Refresh your patch at an 1.186 + opportune time; try an experiment; and if the experiment 1.187 doesn't work out, <command role="hg-cmd">hg revert</command> 1.188 your modifications back to the last time you refreshed.</para> 1.189 1.190 @@ -340,38 +347,39 @@ 1.191 <title>Stacking and tracking patches</title> 1.192 1.193 <para>Once you have finished working on a patch, or need to work 1.194 - on another, you can use the <command role="hg-ext-mq">hg hg 1.195 - qnew</command> command again to create a new patch. 1.196 - Mercurial will apply this patch on top of your existing patch. 1.197 - See figure <xref linkend="ex:mq:qnew2"/> for an example. 1.198 - Notice that the patch contains the changes in our prior patch 1.199 - as part of its context (you can see this more clearly in the 1.200 - output of <command role="hg-cmd">hg 1.201 + on another, you can use the <command 1.202 + role="hg-ext-mq">qnew</command> command again to create a 1.203 + new patch. Mercurial will apply this patch on top of your 1.204 + existing patch.</para> 1.205 + 1.206 +<!-- &interaction.mq.tutorial.qnew2; --> 1.207 + <para>Notice that the patch contains the changes in our prior 1.208 + patch as part of its context (you can see this more clearly in 1.209 + the output of <command role="hg-cmd">hg 1.210 annotate</command>).</para> 1.211 1.212 -<!-- &interaction.mq.tutorial.qnew2; --> 1.213 - 1.214 <para>So far, with the exception of <command 1.215 - role="hg-ext-mq">hg qnew</command> and <command 1.216 - role="hg-ext-mq">hg qrefresh</command>, we've been careful to 1.217 + role="hg-ext-mq">qnew</command> and <command 1.218 + role="hg-ext-mq">qrefresh</command>, we've been careful to 1.219 only use regular Mercurial commands. However, MQ provides 1.220 many commands that are easier to use when you are thinking 1.221 - about patches, as illustrated in figure <xref 1.222 - linkend="ex:mq:qseries"/>:</para> 1.223 + about patches, as illustrated below.</para> 1.224 + 1.225 +<!-- &interaction.mq.tutorial.qseries; --> 1.226 1.227 <itemizedlist> 1.228 <listitem><para>The <command 1.229 - role="hg-ext-mq">hg qseries</command> command lists every 1.230 + role="hg-ext-mq">qseries</command> command lists every 1.231 patch that MQ knows about in this repository, from oldest 1.232 to newest (most recently 1.233 - <emphasis>created</emphasis>).</para></listitem> 1.234 + <emphasis>created</emphasis>).</para> 1.235 + </listitem> 1.236 <listitem><para>The <command 1.237 - role="hg-ext-mq">hg qapplied</command> command lists every 1.238 + role="hg-ext-mq">qapplied</command> command lists every 1.239 patch that MQ has <emphasis>applied</emphasis> in this 1.240 repository, again from oldest to newest (most recently 1.241 - applied).</para></listitem></itemizedlist> 1.242 - 1.243 -<!-- &interaction.mq.tutorial.qseries; --> 1.244 + applied).</para> 1.245 + </listitem></itemizedlist> 1.246 1.247 </sect2> 1.248 <sect2> 1.249 @@ -386,52 +394,53 @@ 1.250 changeset in the repository, and the effects of the patch and 1.251 changeset are visible in the working directory. You can undo 1.252 the application of a patch using the <command 1.253 - role="hg-ext-mq">hg qpop</command> command. MQ still 1.254 + role="hg-ext-mq">qpop</command> command. MQ still 1.255 <emphasis>knows about</emphasis>, or manages, a popped patch, 1.256 but the patch no longer has a corresponding changeset in the 1.257 repository, and the working directory does not contain the 1.258 changes made by the patch. Figure <xref 1.259 - linkend="fig:mq:stack"/> illustrates the difference between 1.260 - applied and tracked patches.</para> 1.261 + linkend="fig:mq:stack"/> illustrates 1.262 + the difference between applied and tracked patches.</para> 1.263 1.264 <informalfigure id="fig:mq:stack"> 1.265 - <mediaobject> 1.266 - <imageobject><imagedata fileref="mq-stack"/></imageobject> 1.267 - <textobject><phrase>XXX add text</phrase></textobject> 1.268 - <caption><para>Applied and unapplied patches in the MQ patch 1.269 - stack</para></caption> 1.270 - </mediaobject> 1.271 + <mediaobject><imageobject><imagedata 1.272 + fileref="mq-stack"/></imageobject><textobject><phrase>XXX 1.273 + add text</phrase></textobject><caption><para>Applied and 1.274 + unapplied patches in the MQ patch 1.275 + stack</para></caption></mediaobject> 1.276 </informalfigure> 1.277 1.278 <para>You can reapply an unapplied, or popped, patch using the 1.279 - <command role="hg-ext-mq">hg qpush</command> command. This 1.280 + <command role="hg-ext-mq">qpush</command> command. This 1.281 creates a new changeset to correspond to the patch, and the 1.282 patch's changes once again become present in the working 1.283 - directory. See figure <xref linkend="ex:mq:qpop"/> for 1.284 - examples of <command role="hg-ext-mq">hg qpop</command> and 1.285 - <command role="hg-ext-mq">hg qpush</command> in action. Notice 1.286 - that once we have popped a patch or two patches, the output of 1.287 - <command role="hg-ext-mq">hg qseries</command> remains the same, 1.288 - while that of <command role="hg-ext-mq">hg qapplied</command> has 1.289 - changed.</para> 1.290 - 1.291 + directory. See below for examples of <command 1.292 + role="hg-ext-mq">qpop</command> and <command 1.293 + role="hg-ext-mq">qpush</command> in action.</para> 1.294 <!-- &interaction.mq.tutorial.qpop; --> 1.295 1.296 + <para>Notice that once we have popped a patch or two patches, 1.297 + the output of <command role="hg-ext-mq">qseries</command> 1.298 + remains the same, while that of <command 1.299 + role="hg-ext-mq">qapplied</command> has changed.</para> 1.300 + 1.301 + 1.302 </sect2> 1.303 <sect2> 1.304 <title>Pushing and popping many patches</title> 1.305 1.306 - <para>While <command role="hg-ext-mq">hg qpush</command> and 1.307 - <command role="hg-ext-mq">hg qpop</command> each operate on a 1.308 + <para>While <command role="hg-ext-mq">qpush</command> and 1.309 + <command role="hg-ext-mq">qpop</command> each operate on a 1.310 single patch at a time by default, you can push and pop many 1.311 patches in one go. The <option 1.312 - role="hg-ext-mq-cmd-qpush-opt">-a</option> option to 1.313 - <command role="hg-ext-mq">hg qpush</command> causes it to push 1.314 + role="hg-ext-mq-cmd-qpush-opt">hg -a</option> option to 1.315 + <command role="hg-ext-mq">qpush</command> causes it to push 1.316 all unapplied patches, while the <option 1.317 role="hg-ext-mq-cmd-qpop-opt">-a</option> option to <command 1.318 - role="hg-ext-mq">hg qpop</command> causes it to pop all applied 1.319 + role="hg-ext-mq">qpop</command> causes it to pop all applied 1.320 patches. (For some more ways to push and pop many patches, 1.321 - see section <xref linkend="sec:mq:perf"/> below.)</para> 1.322 + see section <xref linkend="sec:mq:perf"/> 1.323 + below.)</para> 1.324 1.325 <!-- &interaction.mq.tutorial.qpush-a; --> 1.326 1.327 @@ -442,9 +451,9 @@ 1.328 <para>Several MQ commands check the working directory before 1.329 they do anything, and fail if they find any modifications. 1.330 They do this to ensure that you won't lose any changes that 1.331 - you have made, but not yet incorporated into a patch. Figure 1.332 - <xref linkend="ex:mq:add"/> illustrates this; the <command 1.333 - role="hg-ext-mq">hg qnew</command> command will not create a 1.334 + you have made, but not yet incorporated into a patch. The 1.335 + example below illustrates this; the <command 1.336 + role="hg-ext-mq">qnew</command> command will not create a 1.337 new patch if there are outstanding changes, caused in this 1.338 case by the <command role="hg-cmd">hg add</command> of 1.339 <filename>file3</filename>.</para> 1.340 @@ -456,19 +465,19 @@ 1.341 named <option>-f</option>. The exact meaning of 1.342 <option>-f</option> depends on the command. For example, 1.343 <command role="hg-cmd">hg qnew <option 1.344 - role="hg-ext-mq-cmd-qnew-opt">-f</option></command> will 1.345 - incorporate any outstanding changes into the new patch it 1.346 + role="hg-ext-mq-cmd-qnew-opt">hg -f</option></command> 1.347 + will incorporate any outstanding changes into the new patch it 1.348 creates, but <command role="hg-cmd">hg qpop <option 1.349 - role="hg-ext-mq-cmd-qpop-opt">-f</option></command> will 1.350 - revert modifications to any files affected by the patch that 1.351 - it is popping. Be sure to read the documentation for a 1.352 + role="hg-ext-mq-cmd-qpop-opt">hg -f</option></command> 1.353 + will revert modifications to any files affected by the patch 1.354 + that it is popping. Be sure to read the documentation for a 1.355 command's <option>-f</option> option before you use it!</para> 1.356 1.357 </sect2> 1.358 <sect2> 1.359 <title>Working on several patches at once</title> 1.360 1.361 - <para>The <command role="hg-ext-mq">hg qrefresh</command> command 1.362 + <para>The <command role="hg-ext-mq">qrefresh</command> command 1.363 always refreshes the <emphasis>topmost</emphasis> applied 1.364 patch. This means that you can suspend work on one patch (by 1.365 refreshing it), pop or push to make a different patch the top, 1.366 @@ -478,20 +487,19 @@ 1.367 <para>Here's an example that illustrates how you can use this 1.368 ability. Let's say you're developing a new feature as two 1.369 patches. The first is a change to the core of your software, 1.370 - and the second&emdash;layered on top of the first&emdash;changes the 1.371 - user interface to use the code you just added to the core. If 1.372 - you notice a bug in the core while you're working on the UI 1.373 - patch, it's easy to fix the core. Simply <command 1.374 - role="hg-ext-mq">hg qrefresh</command> the UI patch to save 1.375 - your in-progress changes, and <command 1.376 - role="hg-ext-mq">hg qpop</command> down to the core patch. Fix 1.377 - the core bug, <command role="hg-ext-mq">hg qrefresh</command> the 1.378 - core patch, and <command role="hg-ext-mq">hg qpush</command> back 1.379 + and the second&emdash;layered on top of the 1.380 + first&emdash;changes the user interface to use the code you 1.381 + just added to the core. If you notice a bug in the core while 1.382 + you're working on the UI patch, it's easy to fix the core. 1.383 + Simply <command role="hg-ext-mq">qrefresh</command> the UI 1.384 + patch to save your in-progress changes, and <command 1.385 + role="hg-ext-mq">qpop</command> down to the core patch. Fix 1.386 + the core bug, <command role="hg-ext-mq">qrefresh</command> the 1.387 + core patch, and <command role="hg-ext-mq">qpush</command> back 1.388 to the UI patch to continue where you left off.</para> 1.389 1.390 </sect2> 1.391 </sect1> 1.392 - 1.393 <sect1 id="sec:mq:adv-patch"> 1.394 <title>More about patches</title> 1.395 1.396 @@ -555,19 +563,20 @@ 1.397 <para>If you receive a patch from someone that you want to add 1.398 to your patch queue, and the patch needs a strip count other 1.399 than one, you cannot just <command 1.400 - role="hg-ext-mq">hg qimport</command> the patch, because 1.401 - <command role="hg-ext-mq">hg qimport</command> does not yet have 1.402 + role="hg-ext-mq">qimport</command> the patch, because 1.403 + <command role="hg-ext-mq">qimport</command> does not yet have 1.404 a <literal>-p</literal> option (see <ulink role="hg-bug" 1.405 url="http://www.selenic.com/mercurial/bts/issue311">issue 1.406 311</ulink>). Your best bet is to <command 1.407 - role="hg-ext-mq">hg qnew</command> a patch of your own, then 1.408 + role="hg-ext-mq">qnew</command> a patch of your own, then 1.409 use <command>patch -pN</command> to apply their patch, 1.410 followed by <command role="hg-cmd">hg addremove</command> to 1.411 pick up any files added or removed by the patch, followed by 1.412 - <command role="hg-ext-mq">hg qrefresh</command>. This complexity 1.413 - may become unnecessary; see <ulink role="hg-bug" 1.414 + <command role="hg-ext-mq">hg qrefresh</command>. This 1.415 + complexity may become unnecessary; see <ulink role="hg-bug" 1.416 url="http://www.selenic.com/mercurial/bts/issue311">issue 1.417 - 311</ulink> for details.</para> 1.418 + 311</ulink> for details. 1.419 + </para> 1.420 </sect2> 1.421 <sect2> 1.422 <title>Strategies for applying a patch</title> 1.423 @@ -619,42 +628,39 @@ 1.424 1.425 <para>There are a few useful things to know about how 1.426 <command>patch</command> works with files.</para> 1.427 - 1.428 <itemizedlist> 1.429 <listitem><para>This should already be obvious, but 1.430 <command>patch</command> cannot handle binary 1.431 - files.</para></listitem> 1.432 - 1.433 + files.</para> 1.434 + </listitem> 1.435 <listitem><para>Neither does it care about the executable bit; 1.436 it creates new files as readable, but not 1.437 - executable.</para></listitem> 1.438 - 1.439 + executable.</para> 1.440 + </listitem> 1.441 <listitem><para><command>patch</command> treats the removal of 1.442 a file as a diff between the file to be removed and the 1.443 empty file. So your idea of <quote>I deleted this 1.444 file</quote> looks like <quote>every line of this file 1.445 - was deleted</quote> in a patch.</para></listitem> 1.446 - 1.447 + was deleted</quote> in a patch.</para> 1.448 + </listitem> 1.449 <listitem><para>It treats the addition of a file as a diff 1.450 between the empty file and the file to be added. So in a 1.451 patch, your idea of <quote>I added this file</quote> looks 1.452 like <quote>every line of this file was 1.453 - added</quote>.</para></listitem> 1.454 - 1.455 + added</quote>.</para> 1.456 + </listitem> 1.457 <listitem><para>It treats a renamed file as the removal of the 1.458 old name, and the addition of the new name. This means 1.459 that renamed files have a big footprint in patches. (Note 1.460 also that Mercurial does not currently try to infer when 1.461 - files have been renamed or copied in a 1.462 - patch.)</para></listitem> 1.463 - 1.464 + files have been renamed or copied in a patch.)</para> 1.465 + </listitem> 1.466 <listitem><para><command>patch</command> cannot represent 1.467 empty files, so you cannot use a patch to represent the 1.468 notion <quote>I added this empty file to the 1.469 - tree</quote>.</para></listitem> 1.470 - </itemizedlist> 1.471 - </sect2> 1.472 - 1.473 + tree</quote>.</para> 1.474 + </listitem></itemizedlist> 1.475 + </sect2> 1.476 <sect2> 1.477 <title>Beware the fuzz</title> 1.478 1.479 @@ -664,7 +670,7 @@ 1.480 file. The most common cases typically involve applying a 1.481 patch twice, or at an incorrect location in the file. If 1.482 <command>patch</command> or <command 1.483 - role="hg-ext-mq">hg qpush</command> ever mentions an offset or 1.484 + role="hg-ext-mq">qpush</command> ever mentions an offset or 1.485 fuzz factor, you should make sure that the modified files are 1.486 correct afterwards.</para> 1.487 1.488 @@ -683,7 +689,7 @@ 1.489 <sect2> 1.490 <title>Handling rejection</title> 1.491 1.492 - <para>If <command role="hg-ext-mq">hg qpush</command> fails to 1.493 + <para>If <command role="hg-ext-mq">qpush</command> fails to 1.494 apply a patch, it will print an error message and exit. If it 1.495 has left <filename role="special">.rej</filename> files 1.496 behind, it is usually best to fix up the rejected hunks before 1.497 @@ -692,7 +698,8 @@ 1.498 <para>If your patch <emphasis>used to</emphasis> apply cleanly, 1.499 and no longer does because you've changed the underlying code 1.500 that your patches are based on, Mercurial Queues can help; see 1.501 - section <xref linkend="sec:mq:merge"/> for details.</para> 1.502 + section <xref 1.503 + linkend="sec:mq:merge"/> for details.</para> 1.504 1.505 <para>Unfortunately, there aren't any great techniques for 1.506 dealing with rejected hunks. Most often, you'll need to view 1.507 @@ -715,19 +722,18 @@ 1.508 1.509 <itemizedlist> 1.510 <listitem><para>The context in the middle of a hunk has 1.511 - changed.</para></listitem> 1.512 - 1.513 + changed.</para> 1.514 + </listitem> 1.515 <listitem><para>A hunk is missing some context at the 1.516 - beginning or end.</para></listitem> 1.517 - 1.518 + beginning or end.</para> 1.519 + </listitem> 1.520 <listitem><para>A large hunk might apply better&emdash;either 1.521 - entirely or in part&emdash;if it was broken up into smaller 1.522 - hunks.</para></listitem> 1.523 - 1.524 + entirely or in part&emdash;if it was broken up into 1.525 + smaller hunks.</para> 1.526 + </listitem> 1.527 <listitem><para>A hunk removes lines with slightly different 1.528 - content than those currently present in the 1.529 - file.</para></listitem> 1.530 - </itemizedlist> 1.531 + content than those currently present in the file.</para> 1.532 + </listitem></itemizedlist> 1.533 1.534 <para>If you use <command>wiggle</command> or 1.535 <command>mpatch</command>, you should be doubly careful to 1.536 @@ -754,12 +760,12 @@ 1.537 1.538 <para>On my old, slow laptop, I was able to <command 1.539 role="hg-cmd">hg qpush <option 1.540 - role="hg-ext-mq-cmd-qpush-opt">-a</option></command> all 1.541 + role="hg-ext-mq-cmd-qpush-opt">hg -a</option></command> all 1.542 1,738 patches in 3.5 minutes, and <command role="hg-cmd">hg qpop 1.543 - <option role="hg-ext-mq-cmd-qpop-opt">-a</option></command> 1.544 + <option role="hg-ext-mq-cmd-qpop-opt">hg -a</option></command> 1.545 them all in 30 seconds. (On a newer laptop, the time to push 1.546 all patches dropped to two minutes.) I could <command 1.547 - role="hg-ext-mq">hg qrefresh</command> one of the biggest patches 1.548 + role="hg-ext-mq">qrefresh</command> one of the biggest patches 1.549 (which made 22,779 lines of changes to 287 files) in 6.6 1.550 seconds.</para> 1.551 1.552 @@ -769,23 +775,23 @@ 1.553 1.554 <para>First of all, try to <quote>batch</quote> operations 1.555 together. Every time you run <command 1.556 - role="hg-ext-mq">hg qpush</command> or <command 1.557 - role="hg-ext-mq">hg qpop</command>, these commands scan the 1.558 + role="hg-ext-mq">qpush</command> or <command 1.559 + role="hg-ext-mq">qpop</command>, these commands scan the 1.560 working directory once to make sure you haven't made some 1.561 changes and then forgotten to run <command 1.562 - role="hg-ext-mq">hg qrefresh</command>. On a small tree, the 1.563 + role="hg-ext-mq">qrefresh</command>. On a small tree, the 1.564 time that this scan takes is unnoticeable. However, on a 1.565 medium-sized tree (containing tens of thousands of files), it 1.566 can take a second or more.</para> 1.567 1.568 - <para>The <command role="hg-ext-mq">hg qpush</command> and <command 1.569 - role="hg-ext-mq">hg qpop</command> commands allow you to push and 1.570 + <para>The <command role="hg-ext-mq">qpush</command> and <command 1.571 + role="hg-ext-mq">qpop</command> commands allow you to push and 1.572 pop multiple patches at a time. You can identify the 1.573 <quote>destination patch</quote> that you want to end up at. 1.574 - When you <command role="hg-ext-mq">hg qpush</command> with a 1.575 + When you <command role="hg-ext-mq">qpush</command> with a 1.576 destination specified, it will push patches until that patch is 1.577 at the top of the applied stack. When you <command 1.578 - role="hg-ext-mq">hg qpop</command> to a destination, MQ will pop 1.579 + role="hg-ext-mq">qpop</command> to a destination, MQ will pop 1.580 patches until the destination patch is at the top.</para> 1.581 1.582 <para>You can identify a destination patch using either the name 1.583 @@ -794,7 +800,6 @@ 1.584 is zero, the second is one, and so on.</para> 1.585 1.586 </sect1> 1.587 - 1.588 <sect1 id="sec:mq:merge"> 1.589 <title>Updating your patches when the underlying code 1.590 changes</title> 1.591 @@ -809,15 +814,14 @@ 1.592 series.</para> 1.593 1.594 <para>The simplest way to do this is to <command role="hg-cmd">hg 1.595 - qpop <option 1.596 - role="hg-ext-mq-cmd-qpop-opt">-a</option></command> your 1.597 - patches, then <command role="hg-cmd">hg pull</command> changes 1.598 - into the underlying repository, and finally <command 1.599 - role="hg-cmd">hg qpush <option 1.600 - role="hg-ext-mq-cmd-qpop-opt">-a</option></command> your 1.601 + qpop <option role="hg-ext-mq-cmd-qpop-opt">hg 1.602 + -a</option></command> your patches, then <command 1.603 + role="hg-cmd">hg pull</command> changes into the underlying 1.604 + repository, and finally <command role="hg-cmd">hg qpush <option 1.605 + role="hg-ext-mq-cmd-qpop-opt">hg -a</option></command> your 1.606 patches again. MQ will stop pushing any time it runs across a 1.607 patch that fails to apply during conflicts, allowing you to fix 1.608 - your conflicts, <command role="hg-ext-mq">hg qrefresh</command> the 1.609 + your conflicts, <command role="hg-ext-mq">qrefresh</command> the 1.610 affected patch, and continue pushing until you have fixed your 1.611 entire stack.</para> 1.612 1.613 @@ -828,8 +832,8 @@ 1.614 fixing up rejected hunks by hand quickly becomes 1.615 tiresome.</para> 1.616 1.617 - <para>It's possible to partially automate the rebasing process. If 1.618 - your patches apply cleanly against some revision of the 1.619 + <para>It's possible to partially automate the rebasing process. 1.620 + If your patches apply cleanly against some revision of the 1.621 underlying repo, MQ can use this information to help you to 1.622 resolve conflicts between your patches and a different 1.623 revision.</para> 1.624 @@ -838,12 +842,12 @@ 1.625 <orderedlist> 1.626 <listitem><para>To begin, <command role="hg-cmd">hg qpush 1.627 -a</command> all of your patches on top of the revision 1.628 - where you know that they apply cleanly.</para></listitem> 1.629 - 1.630 + where you know that they apply cleanly.</para> 1.631 + </listitem> 1.632 <listitem><para>Save a backup copy of your patch directory using 1.633 <command role="hg-cmd">hg qsave <option 1.634 - role="hg-ext-mq-cmd-qsave-opt">-e</option> <option 1.635 - role="hg-ext-mq-cmd-qsave-opt">-c</option></command>. 1.636 + role="hg-ext-mq-cmd-qsave-opt">hg -e</option> <option 1.637 + role="hg-ext-mq-cmd-qsave-opt">hg -c</option></command>. 1.638 This prints the name of the directory that it has saved the 1.639 patches in. It will save the patches to a directory called 1.640 <filename role="special" 1.641 @@ -852,36 +856,34 @@ 1.642 <quote>save changeset</quote> on top of your applied 1.643 patches; this is for internal book-keeping, and records the 1.644 states of the <filename role="special">series</filename> and 1.645 - <filename role="special">status</filename> 1.646 - files.</para></listitem> 1.647 - 1.648 - <listitem> 1.649 - <para>Use <command role="hg-cmd">hg pull</command> to bring 1.650 - new changes into the underlying repository. (Don't run 1.651 - <command role="hg-cmd">hg pull -u</command>; see below for 1.652 - why.)</para></listitem> 1.653 - 1.654 + <filename role="special">status</filename> files.</para> 1.655 + </listitem> 1.656 + <listitem><para>Use <command role="hg-cmd">hg pull</command> to 1.657 + bring new changes into the underlying repository. (Don't 1.658 + run <command role="hg-cmd">hg pull -u</command>; see below 1.659 + for why.)</para> 1.660 + </listitem> 1.661 <listitem><para>Update to the new tip revision, using <command 1.662 role="hg-cmd">hg update <option 1.663 role="hg-opt-update">-C</option></command> to override 1.664 - the patches you have pushed.</para></listitem> 1.665 - 1.666 + the patches you have pushed.</para> 1.667 + </listitem> 1.668 <listitem><para>Merge all patches using 1.669 - \hgcmdargs{qpush}{<option 1.670 - role="hg-ext-mq-cmd-qpush-opt">-m</option> <option 1.671 - role="hg-ext-mq-cmd-qpush-opt">-a</option>}. The <option 1.672 - role="hg-ext-mq-cmd-qpush-opt">-m</option> option to 1.673 - <command role="hg-ext-mq">hg qpush</command> tells MQ to 1.674 + \hgcmdargs{qpush}{<option role="hg-ext-mq-cmd-qpush-opt">hg 1.675 + -m</option> <option role="hg-ext-mq-cmd-qpush-opt">hg 1.676 + -a</option>}. The <option 1.677 + role="hg-ext-mq-cmd-qpush-opt">hg -m</option> option to 1.678 + <command role="hg-ext-mq">qpush</command> tells MQ to 1.679 perform a three-way merge if the patch fails to 1.680 - apply.</para></listitem> 1.681 - </orderedlist> 1.682 + apply.</para> 1.683 + </listitem></orderedlist> 1.684 1.685 <para>During the <command role="hg-cmd">hg qpush <option 1.686 - role="hg-ext-mq-cmd-qpush-opt">-m</option></command>, each 1.687 - patch in the <filename role="special">series</filename> file is 1.688 - applied normally. If a patch applies with fuzz or rejects, MQ 1.689 - looks at the queue you <command 1.690 - role="hg-ext-mq">hg qsave</command>d, and performs a three-way 1.691 + role="hg-ext-mq-cmd-qpush-opt">hg -m</option></command>, 1.692 + each patch in the <filename role="special">series</filename> 1.693 + file is applied normally. If a patch applies with fuzz or 1.694 + rejects, MQ looks at the queue you <command 1.695 + role="hg-ext-mq">qsave</command>d, and performs a three-way 1.696 merge with the corresponding changeset. This merge uses 1.697 Mercurial's normal merge machinery, so it may pop up a GUI merge 1.698 tool to help you to resolve problems.</para> 1.699 @@ -893,9 +895,7 @@ 1.700 extra head from the old patch queue, and a copy of the old patch 1.701 queue will be in <filename role="special" 1.702 class="directory">.hg/patches.N</filename>. You can remove the 1.703 - extra head using <command role="hg-cmd">hg qpop <option 1.704 - role="hg-ext-mq-cmd-qpop-opt">-a</option> <option 1.705 - role="hg-ext-mq-cmd-qpop-opt">-n</option> 1.706 + extra head using <command role="hg-cmd">hg qpop -a -n 1.707 patches.N</command> or <command role="hg-cmd">hg 1.708 strip</command>. You can delete <filename role="special" 1.709 class="directory">.hg/patches.N</filename> once you are sure 1.710 @@ -908,7 +908,7 @@ 1.711 <para>MQ commands that work with patches let you refer to a patch 1.712 either by using its name or by a number. By name is obvious 1.713 enough; pass the name <filename>foo.patch</filename> to <command 1.714 - role="hg-ext-mq">hg qpush</command>, for example, and it will 1.715 + role="hg-ext-mq">qpush</command>, for example, and it will 1.716 push patches until <filename>foo.patch</filename> is 1.717 applied.</para> 1.718 1.719 @@ -920,7 +920,7 @@ 1.720 1.721 <para>Referring to a patch by index isn't much different. The 1.722 first patch printed in the output of <command 1.723 - role="hg-ext-mq">hg qseries</command> is patch zero (yes, it's 1.724 + role="hg-ext-mq">qseries</command> is patch zero (yes, it's 1.725 one of those start-at-zero counting systems); the second is 1.726 patch one; and so on.</para> 1.727 1.728 @@ -941,19 +941,18 @@ 1.729 <itemizedlist> 1.730 <listitem><para>Want to patchbomb a mailing list with your 1.731 latest series of changes?</para> 1.732 - <programlisting> 1.733 - hg email qbase:qtip 1.734 - </programlisting></listitem> 1.735 - <listitem><para> (Don't know what <quote>patchbombing</quote> 1.736 - is? See section <xref 1.737 - linkend="sec:hgext:patchbomb"/>.)</para></listitem> 1.738 - 1.739 + <programlisting>hg email qbase:qtip 1.740 + </programlisting> 1.741 + <para> (Don't know what <quote>patchbombing</quote> is? See 1.742 + section <xref linkend="sec:hgext:patchbomb"/>.)</para> 1.743 + </listitem> 1.744 <listitem><para>Need to see all of the patches since 1.745 <literal>foo.patch</literal> that have touched files in a 1.746 subdirectory of your tree?</para> 1.747 <programlisting> 1.748 hg log -r foo.patch:qtip <emphasis>subdir</emphasis> 1.749 - </programlisting></listitem> 1.750 + </programlisting> 1.751 + </listitem> 1.752 </itemizedlist> 1.753 1.754 <para>Because MQ makes the names of patches available to the rest 1.755 @@ -961,16 +960,16 @@ 1.756 don't need to type in the entire name of a patch when you want 1.757 to identify it by name.</para> 1.758 1.759 -<!-- &interaction.mq.id.output; --> 1.760 - 1.761 <para>Another nice consequence of representing patch names as tags 1.762 is that when you run the <command role="hg-cmd">hg log</command> 1.763 command, it will display a patch's name as a tag, simply as part 1.764 of its normal output. This makes it easy to visually 1.765 distinguish applied patches from underlying 1.766 - <quote>normal</quote> revisions. Figure <xref 1.767 - linkend="ex:mq:id"/> shows a few normal Mercurial commands in 1.768 - use with applied patches.</para> 1.769 + <quote>normal</quote> revisions. The following example shows a 1.770 + few normal Mercurial commands in use with applied 1.771 + patches.</para> 1.772 + 1.773 +<!-- &interaction.mq.id.output; --> 1.774 1.775 </sect1> 1.776 <sect1> 1.777 @@ -982,25 +981,24 @@ 1.778 1.779 <itemizedlist> 1.780 <listitem><para>Normally, when you <command 1.781 - role="hg-ext-mq">hg qpop</command> a patch and <command 1.782 - role="hg-ext-mq">hg qpush</command> it again, the changeset 1.783 + role="hg-ext-mq">qpop</command> a patch and <command 1.784 + role="hg-ext-mq">qpush</command> it again, the changeset 1.785 that represents the patch after the pop/push will have a 1.786 <emphasis>different identity</emphasis> than the changeset 1.787 that represented the hash beforehand. See section <xref 1.788 - linkend="sec:mqref:cmd:qpush"/> for information as to why 1.789 - this is.</para></listitem> 1.790 - 1.791 + linkend="sec:mqref:cmd:qpush"/> for 1.792 + information as to why this is.</para> 1.793 + </listitem> 1.794 <listitem><para>It's not a good idea to <command 1.795 role="hg-cmd">hg merge</command> changes from another 1.796 branch with a patch changeset, at least if you want to 1.797 maintain the <quote>patchiness</quote> of that changeset and 1.798 changesets below it on the patch stack. If you try to do 1.799 this, it will appear to succeed, but MQ will become 1.800 - confused.</para></listitem> 1.801 - </itemizedlist> 1.802 - 1.803 - </sect1> 1.804 - 1.805 + confused.</para> 1.806 + </listitem></itemizedlist> 1.807 + 1.808 + </sect1> 1.809 <sect1 id="sec:mq:repo"> 1.810 <title>Managing patches in a repository</title> 1.811 1.812 @@ -1014,7 +1012,7 @@ 1.813 contents of the patch directory as a Mercurial repository in its 1.814 own right. This can be a useful way to work. For example, you 1.815 can work on a patch for a while, <command 1.816 - role="hg-ext-mq">hg qrefresh</command> it, then <command 1.817 + role="hg-ext-mq">qrefresh</command> it, then <command 1.818 role="hg-cmd">hg commit</command> the current state of the 1.819 patch. This lets you <quote>roll back</quote> to that version 1.820 of the patch later on.</para> 1.821 @@ -1040,25 +1038,24 @@ 1.822 <para>MQ helps you to work with the <filename role="special" 1.823 class="directory">.hg/patches</filename> directory as a 1.824 repository; when you prepare a repository for working with 1.825 - patches using <command role="hg-ext-mq">hg qinit</command>, you 1.826 - can pass the <option 1.827 - role="hg-ext-mq-cmd-qinit-opt">-c</option> option to create 1.828 - the <filename role="special" 1.829 + patches using <command role="hg-ext-mq">qinit</command>, you 1.830 + can pass the <option role="hg-ext-mq-cmd-qinit-opt">hg 1.831 + -c</option> option to create the <filename role="special" 1.832 class="directory">.hg/patches</filename> directory as a 1.833 Mercurial repository.</para> 1.834 1.835 <note> 1.836 <para> If you forget to use the <option 1.837 - role="hg-ext-mq-cmd-qinit-opt">-c</option> option, you can 1.838 - simply go into the <filename role="special" 1.839 + role="hg-ext-mq-cmd-qinit-opt">hg -c</option> option, you 1.840 + can simply go into the <filename role="special" 1.841 class="directory">.hg/patches</filename> directory at any 1.842 - time and run <command role="hg-cmd">hg init</command>. Don't 1.843 - forget to add an entry for the <filename 1.844 + time and run <command role="hg-cmd">hg init</command>. 1.845 + Don't forget to add an entry for the <filename 1.846 role="special">status</filename> file to the <filename 1.847 role="special">.hgignore</filename> file, though</para> 1.848 1.849 <para> (<command role="hg-cmd">hg qinit <option 1.850 - role="hg-ext-mq-cmd-qinit-opt">-c</option></command> 1.851 + role="hg-ext-mq-cmd-qinit-opt">hg -c</option></command> 1.852 does this for you automatically); you 1.853 <emphasis>really</emphasis> don't want to manage the 1.854 <filename role="special">status</filename> file.</para> 1.855 @@ -1070,7 +1067,7 @@ 1.856 add</command> every patch that you create and import.</para> 1.857 1.858 <para>MQ provides a shortcut command, <command 1.859 - role="hg-ext-mq">hg qcommit</command>, that runs <command 1.860 + role="hg-ext-mq">qcommit</command>, that runs <command 1.861 role="hg-cmd">hg commit</command> in the <filename 1.862 role="special" class="directory">.hg/patches</filename> 1.863 directory. This saves some bothersome typing.</para> 1.864 @@ -1079,12 +1076,11 @@ 1.865 you can define the alias <command>mq</command> on Unix 1.866 systems. For example, on Linux systems using the 1.867 <command>bash</command> shell, you can include the following 1.868 - snippet in your <filename role="home"> 1.869 - /.bashrc</filename>.</para> 1.870 - 1.871 - <programlisting> 1.872 - alias mq=`hg -R $(hg root)/.hg/patches' 1.873 - </programlisting> 1.874 + snippet in your <filename 1.875 + role="home">~/.bashrc</filename>.</para> 1.876 + 1.877 + <programlisting>alias mq=`hg -R $(hg 1.878 + root)/.hg/patches'</programlisting> 1.879 1.880 <para>You can then issue commands of the form <command>mq 1.881 pull</command> from the main repository.</para> 1.882 @@ -1102,9 +1098,9 @@ 1.883 update</command> changes to patches or the <filename 1.884 role="special">series</filename> file, you will have to 1.885 <command role="hg-cmd">hg qpop <option 1.886 - role="hg-ext-mq-cmd-qpop-opt">-a</option></command> and 1.887 + role="hg-ext-mq-cmd-qpop-opt">hg -a</option></command> and 1.888 then <command role="hg-cmd">hg qpush <option 1.889 - role="hg-ext-mq-cmd-qpush-opt">-a</option></command> in 1.890 + role="hg-ext-mq-cmd-qpush-opt">hg -a</option></command> in 1.891 the underlying repository to see those changes show up there. 1.892 If you forget to do this, you can confuse MQ's idea of which 1.893 patches are applied.</para> 1.894 @@ -1121,9 +1117,9 @@ 1.895 <para>The <command>diffstat</command> command 1.896 <citation>web:diffstat</citation> generates a histogram of the 1.897 modifications made to each file in a patch. It provides a good 1.898 - way to <quote>get a sense of</quote> a patch&emdash;which files it 1.899 - affects, and how much change it introduces to each file and as a 1.900 - whole. (I find that it's a good idea to use 1.901 + way to <quote>get a sense of</quote> a patch&emdash;which files 1.902 + it affects, and how much change it introduces to each file and 1.903 + as a whole. (I find that it's a good idea to use 1.904 <command>diffstat</command>'s <option 1.905 role="cmd-opt-diffstat">-p</option> option as a matter of 1.906 course, as otherwise it will try to do clever things with 1.907 @@ -1162,30 +1158,30 @@ 1.908 the patch is. Long names shouldn't be a problem; you won't be 1.909 typing the names often, but you <emphasis>will</emphasis> be 1.910 running commands like <command 1.911 - role="hg-ext-mq">hg qapplied</command> and <command 1.912 - role="hg-ext-mq">hg qtop</command> over and over. Good naming 1.913 + role="hg-ext-mq">qapplied</command> and <command 1.914 + role="hg-ext-mq">qtop</command> over and over. Good naming 1.915 becomes especially important when you have a number of patches 1.916 to work with, or if you are juggling a number of different tasks 1.917 and your patches only get a fraction of your attention.</para> 1.918 1.919 <para>Be aware of what patch you're working on. Use the <command 1.920 - role="hg-ext-mq">hg qtop</command> command and skim over the text 1.921 + role="hg-ext-mq">qtop</command> command and skim over the text 1.922 of your patches frequently&emdash;for example, using <command 1.923 role="hg-cmd">hg tip <option 1.924 - role="hg-opt-tip">-p</option></command>)&emdash;to be sure of 1.925 - where you stand. I have several times worked on and <command 1.926 - role="hg-ext-mq">hg qrefresh</command>ed a patch other than the 1.927 + role="hg-opt-tip">-p</option></command>)&emdash;to be sure 1.928 + of where you stand. I have several times worked on and <command 1.929 + role="hg-ext-mq">qrefresh</command>ed a patch other than the 1.930 one I intended, and it's often tricky to migrate changes into 1.931 the right patch after making them in the wrong one.</para> 1.932 1.933 <para>For this reason, it is very much worth investing a little 1.934 time to learn how to use some of the third-party tools I 1.935 described in section <xref linkend="sec:mq:tools"/>, 1.936 - particularly <command>diffstat</command> and 1.937 - <command>filterdiff</command>. The former will give you a quick 1.938 - idea of what changes your patch is making, while the latter 1.939 - makes it easy to splice hunks selectively out of one patch and 1.940 - into another.</para> 1.941 + particularly 1.942 + <command>diffstat</command> and <command>filterdiff</command>. 1.943 + The former will give you a quick idea of what changes your patch 1.944 + is making, while the latter makes it easy to splice hunks 1.945 + selectively out of one patch and into another.</para> 1.946 1.947 </sect1> 1.948 <sect1> 1.949 @@ -1225,7 +1221,7 @@ 1.950 <title>Combining entire patches</title> 1.951 1.952 <para>MQ provides a command, <command 1.953 - role="hg-ext-mq">hg qfold</command> that lets you combine 1.954 + role="hg-ext-mq">qfold</command> that lets you combine 1.955 entire patches. This <quote>folds</quote> the patches you 1.956 name, in the order you name them, into the topmost applied 1.957 patch, and concatenates their descriptions onto the end of its 1.958 @@ -1234,7 +1230,7 @@ 1.959 1.960 <para>The order in which you fold patches matters. If your 1.961 topmost applied patch is <literal>foo</literal>, and you 1.962 - <command role="hg-ext-mq">hg qfold</command> 1.963 + <command role="hg-ext-mq">qfold</command> 1.964 <literal>bar</literal> and <literal>quux</literal> into it, 1.965 you will end up with a patch that has the same effect as if 1.966 you applied first <literal>foo</literal>, then 1.967 @@ -1257,9 +1253,9 @@ 1.968 output onto the end of the patch you want to merge into. You 1.969 usually won't need to modify the patch you've merged the 1.970 changes from. Instead, MQ will report some rejected hunks 1.971 - when you <command role="hg-ext-mq">hg qpush</command> it (from 1.972 + when you <command role="hg-ext-mq">qpush</command> it (from 1.973 the hunks you moved into the other patch), and you can simply 1.974 - <command role="hg-ext-mq">hg qrefresh</command> the patch to drop 1.975 + <command role="hg-ext-mq">qrefresh</command> the patch to drop 1.976 the duplicate hunks.</para> 1.977 1.978 <para>If you have a patch that has multiple hunks modifying a 1.979 @@ -1273,16 +1269,14 @@ 1.980 <itemizedlist> 1.981 <listitem><para>(in the first column) a <emphasis>file 1.982 number</emphasis> to identify each file modified in the 1.983 - patch;</para></listitem> 1.984 - 1.985 + patch;</para> 1.986 + </listitem> 1.987 <listitem><para>(on the next line, indented) the line number 1.988 - within a modified file where a hunk starts; 1.989 - and</para></listitem> 1.990 - 1.991 + within a modified file where a hunk starts; and</para> 1.992 + </listitem> 1.993 <listitem><para>(on the same line) a <emphasis>hunk 1.994 - number</emphasis> to identify that 1.995 - hunk.</para></listitem> 1.996 - </itemizedlist> 1.997 + number</emphasis> to identify that hunk.</para> 1.998 + </listitem></itemizedlist> 1.999 1.1000 <para>You'll have to use some visual inspection, and reading of 1.1001 the patch, to identify the file and hunk numbers you'll want,