1.1 --- a/en/mq-collab.tex	Sun May 27 09:40:12 2007 -0700
     1.2 +++ b/en/mq-collab.tex	Sun May 27 09:41:55 2007 -0700
     1.3 @@ -108,7 +108,7 @@
     1.4  
     1.5  \section{Controlling the guards on a patch}
     1.6  
     1.7 -The \hgcmd{qguard} command lets you determine which guards should
     1.8 +The \hgxcmd{mq}{qguard} command lets you determine which guards should
     1.9  apply to a patch, or display the guards that are already in effect.
    1.10  Without any arguments, it displays the guards on the current topmost
    1.11  patch.
    1.12 @@ -121,7 +121,7 @@
    1.13  \interaction{mq.guards.qguard.neg}
    1.14  
    1.15  \begin{note}
    1.16 -  The \hgcmd{qguard} command \emph{sets} the guards on a patch; it
    1.17 +  The \hgxcmd{mq}{qguard} command \emph{sets} the guards on a patch; it
    1.18    doesn't \emph{modify} them.  What this means is that if you run
    1.19    \hgcmdargs{qguard}{+a +b} on a patch, then \hgcmdargs{qguard}{+c} on
    1.20    the same patch, the \emph{only} guard that will be set on it
    1.21 @@ -130,20 +130,20 @@
    1.22  
    1.23  Mercurial stores guards in the \sfilename{series} file; the form in
    1.24  which they are stored is easy both to understand and to edit by hand.
    1.25 -(In other words, you don't have to use the \hgcmd{qguard} command if
    1.26 +(In other words, you don't have to use the \hgxcmd{mq}{qguard} command if
    1.27  you don't want to; it's okay to simply edit the \sfilename{series}
    1.28  file.)
    1.29  \interaction{mq.guards.series}
    1.30  
    1.31  \section{Selecting the guards to use}
    1.32  
    1.33 -The \hgcmd{qselect} command determines which guards are active at a
    1.34 +The \hgxcmd{mq}{qselect} command determines which guards are active at a
    1.35  given time.  The effect of this is to determine which patches MQ will
    1.36 -apply the next time you run \hgcmd{qpush}.  It has no other effect; in
    1.37 +apply the next time you run \hgxcmd{mq}{qpush}.  It has no other effect; in
    1.38  particular, it doesn't do anything to patches that are already
    1.39  applied.
    1.40  
    1.41 -With no arguments, the \hgcmd{qselect} command lists the guards
    1.42 +With no arguments, the \hgxcmd{mq}{qselect} command lists the guards
    1.43  currently in effect, one per line of output.  Each argument is treated
    1.44  as the name of a guard to apply.
    1.45  \interaction{mq.guards.qselect.foo}
    1.46 @@ -151,7 +151,7 @@
    1.47  the \sfilename{guards} file.
    1.48  \interaction{mq.guards.qselect.cat}
    1.49  We can see the effect the selected guards have when we run
    1.50 -\hgcmd{qpush}.
    1.51 +\hgxcmd{mq}{qpush}.
    1.52  \interaction{mq.guards.qselect.qpush}
    1.53  
    1.54  A guard cannot start with a ``\texttt{+}'' or ``\texttt{-}''

     2.1 --- a/en/mq-ref.tex	Sun May 27 09:40:12 2007 -0700
     2.2 +++ b/en/mq-ref.tex	Sun May 27 09:41:55 2007 -0700
     2.3 @@ -7,26 +7,26 @@
     2.4  For an overview of the commands provided by MQ, use the command
     2.5  \hgcmdargs{help}{mq}.
     2.6  
     2.7 -\subsection{\hgcmd{qapplied}---print applied patches}
     2.8 -
     2.9 -The \hgcmd{qapplied} command prints the current stack of applied
    2.10 +\subsection{\hgxcmd{mq}{qapplied}---print applied patches}
    2.11 +
    2.12 +The \hgxcmd{mq}{qapplied} command prints the current stack of applied
    2.13  patches.  Patches are printed in oldest-to-newest order, so the last
    2.14  patch in the list is the ``top'' patch.
    2.15  
    2.16 -\subsection{\hgcmd{qcommit}---commit changes in the queue repository}
    2.17 -
    2.18 -The \hgcmd{qcommit} command commits any outstanding changes in the
    2.19 +\subsection{\hgxcmd{mq}{qcommit}---commit changes in the queue repository}
    2.20 +
    2.21 +The \hgxcmd{mq}{qcommit} command commits any outstanding changes in the
    2.22  \sdirname{.hg/patches} repository.  This command only works if the
    2.23  \sdirname{.hg/patches} directory is a repository, i.e.~you created the
    2.24  directory using \hgcmdargs{qinit}{\hgopt{qinit}{-c}} or ran
    2.25 -\hgcmd{init} in the directory after running \hgcmd{qinit}.
    2.26 +\hgcmd{init} in the directory after running \hgxcmd{mq}{qinit}.
    2.27  
    2.28  This command is shorthand for \hgcmdargs{commit}{--cwd .hg/patches}.
    2.29  
    2.30 -\subsection{\hgcmd{qdelete}---delete a patch from the
    2.31 +\subsection{\hgxcmd{mq}{qdelete}---delete a patch from the
    2.32    \sfilename{series} file}
    2.33  
    2.34 -The \hgcmd{qdelete} command removes the entry for a patch from the
    2.35 +The \hgxcmd{mq}{qdelete} command removes the entry for a patch from the
    2.36  \sfilename{series} file in the \sdirname{.hg/patches} directory.  It
    2.37  does not pop the patch if the patch is already applied.  By default,
    2.38  it does not delete the patch file; use the \hgopt{qdel}{-f} option to
    2.39 @@ -37,18 +37,18 @@
    2.40  \item[\hgopt{qdel}{-f}] Delete the patch file.
    2.41  \end{itemize}
    2.42  
    2.43 -\subsection{\hgcmd{qdiff}---print a diff of the topmost applied patch}
    2.44 -
    2.45 -The \hgcmd{qdiff} command prints a diff of the topmost applied patch.
    2.46 +\subsection{\hgxcmd{mq}{qdiff}---print a diff of the topmost applied patch}
    2.47 +
    2.48 +The \hgxcmd{mq}{qdiff} command prints a diff of the topmost applied patch.
    2.49  It is equivalent to \hgcmdargs{diff}{-r-2:-1}.
    2.50  
    2.51 -\subsection{\hgcmd{qfold}---merge (``fold'') several patches into one}
    2.52 -
    2.53 -The \hgcmd{qfold} command merges multiple patches into the topmost
    2.54 +\subsection{\hgxcmd{mq}{qfold}---merge (``fold'') several patches into one}
    2.55 +
    2.56 +The \hgxcmd{mq}{qfold} command merges multiple patches into the topmost
    2.57  applied patch, so that the topmost applied patch makes the union of
    2.58  all of the changes in the patches in question.
    2.59  
    2.60 -The patches to fold must not be applied; \hgcmd{qfold} will exit with
    2.61 +The patches to fold must not be applied; \hgxcmd{mq}{qfold} will exit with
    2.62  an error if any is.  The order in which patches are folded is
    2.63  significant; \hgcmdargs{qfold}{a b} means ``apply the current topmost
    2.64  patch, followed by \texttt{a}, followed by \texttt{b}''.
    2.65 @@ -69,26 +69,26 @@
    2.66    and patch description for the folded patch.
    2.67  \end{itemize}
    2.68  
    2.69 -\subsection{\hgcmd{qheader}---display the header/description of a patch}
    2.70 -
    2.71 -The \hgcmd{qheader} command prints the header, or description, of a
    2.72 +\subsection{\hgxcmd{mq}{qheader}---display the header/description of a patch}
    2.73 +
    2.74 +The \hgxcmd{mq}{qheader} command prints the header, or description, of a
    2.75  patch.  By default, it prints the header of the topmost applied patch.
    2.76  Given an argument, it prints the header of the named patch.
    2.77  
    2.78 -\subsection{\hgcmd{qimport}---import a third-party patch into the queue}
    2.79 -
    2.80 -The \hgcmd{qimport} command adds an entry for an external patch to the
    2.81 +\subsection{\hgxcmd{mq}{qimport}---import a third-party patch into the queue}
    2.82 +
    2.83 +The \hgxcmd{mq}{qimport} command adds an entry for an external patch to the
    2.84  \sfilename{series} file, and copies the patch into the
    2.85  \sdirname{.hg/patches} directory.  It adds the entry immediately after
    2.86  the topmost applied patch, but does not push the patch.
    2.87  
    2.88  If the \sdirname{.hg/patches} directory is a repository,
    2.89 -\hgcmd{qimport} automatically does an \hgcmd{add} of the imported
    2.90 +\hgxcmd{mq}{qimport} automatically does an \hgcmd{add} of the imported
    2.91  patch.
    2.92  
    2.93 -\subsection{\hgcmd{qinit}---prepare a repository to work with MQ}
    2.94 -
    2.95 -The \hgcmd{qinit} command prepares a repository to work with MQ.  It
    2.96 +\subsection{\hgxcmd{mq}{qinit}---prepare a repository to work with MQ}
    2.97 +
    2.98 +The \hgxcmd{mq}{qinit} command prepares a repository to work with MQ.  It
    2.99  creates a directory called \sdirname{.hg/patches}.
   2.100  
   2.101  Options:
   2.102 @@ -99,20 +99,20 @@
   2.103  \end{itemize}
   2.104  
   2.105  When the \sdirname{.hg/patches} directory is a repository, the
   2.106 -\hgcmd{qimport} and \hgcmd{qnew} commands automatically \hgcmd{add}
   2.107 +\hgxcmd{mq}{qimport} and \hgxcmd{mq}{qnew} commands automatically \hgcmd{add}
   2.108  new patches.
   2.109  
   2.110 -\subsection{\hgcmd{qnew}---create a new patch}
   2.111 -
   2.112 -The \hgcmd{qnew} command creates a new patch.  It takes one mandatory
   2.113 +\subsection{\hgxcmd{mq}{qnew}---create a new patch}
   2.114 +
   2.115 +The \hgxcmd{mq}{qnew} command creates a new patch.  It takes one mandatory
   2.116  argument, the name to use for the patch file.  The newly created patch
   2.117  is created empty by default.  It is added to the \sfilename{series}
   2.118  file after the current topmost applied patch, and is immediately
   2.119  pushed on top of that patch.
   2.120  
   2.121 -If \hgcmd{qnew} finds modified files in the working directory, it will
   2.122 +If \hgxcmd{mq}{qnew} finds modified files in the working directory, it will
   2.123  refuse to create a new patch unless the \hgopt{qnew}{-f} option is
   2.124 -used (see below).  This behaviour allows you to \hgcmd{qrefresh} your
   2.125 +used (see below).  This behaviour allows you to \hgxcmd{mq}{qrefresh} your
   2.126  topmost applied patch before you apply a new patch on top of it.
   2.127  
   2.128  Options:
   2.129 @@ -126,15 +126,15 @@
   2.130    the patch data.
   2.131  \end{itemize}
   2.132  
   2.133 -\subsection{\hgcmd{qnext}---print the name of the next patch}
   2.134 -
   2.135 -The \hgcmd{qnext} command prints the name name of the next patch in
   2.136 +\subsection{\hgxcmd{mq}{qnext}---print the name of the next patch}
   2.137 +
   2.138 +The \hgxcmd{mq}{qnext} command prints the name name of the next patch in
   2.139  the \sfilename{series} file after the topmost applied patch.  This
   2.140 -patch will become the topmost applied patch if you run \hgcmd{qpush}.
   2.141 -
   2.142 -\subsection{\hgcmd{qpop}---pop patches off the stack}
   2.143 -
   2.144 -The \hgcmd{qpop} command removes applied patches from the top of the
   2.145 +patch will become the topmost applied patch if you run \hgxcmd{mq}{qpush}.
   2.146 +
   2.147 +\subsection{\hgxcmd{mq}{qpop}---pop patches off the stack}
   2.148 +
   2.149 +The \hgxcmd{mq}{qpop} command removes applied patches from the top of the
   2.150  stack of applied patches.  By default, it removes only one patch.
   2.151  
   2.152  This command removes the changesets that represent the popped patches
   2.153 @@ -144,18 +144,18 @@
   2.154  This command takes an optional argument, which it uses as the name or
   2.155  index of the patch to pop to.  If given a name, it will pop patches
   2.156  until the named patch is the topmost applied patch.  If given a
   2.157 -number, \hgcmd{qpop} treats the number as an index into the entries in
   2.158 +number, \hgxcmd{mq}{qpop} treats the number as an index into the entries in
   2.159  the series file, counting from zero (empty lines and lines containing
   2.160  only comments do not count).  It pops patches until the patch
   2.161  identified by the given index is the topmost applied patch.
   2.162  
   2.163 -The \hgcmd{qpop} command does not read or write patches or the
   2.164 -\sfilename{series} file.  It is thus safe to \hgcmd{qpop} a patch that
   2.165 +The \hgxcmd{mq}{qpop} command does not read or write patches or the
   2.166 +\sfilename{series} file.  It is thus safe to \hgxcmd{mq}{qpop} a patch that
   2.167  you have removed from the \sfilename{series} file, or a patch that you
   2.168  have renamed or deleted entirely.  In the latter two cases, use the
   2.169  name of the patch as it was when you applied it.
   2.170  
   2.171 -By default, the \hgcmd{qpop} command will not pop any patches if the
   2.172 +By default, the \hgxcmd{mq}{qpop} command will not pop any patches if the
   2.173  working directory has been modified.  You can override this behaviour
   2.174  using the \hgopt{qpop}{-f} option, which reverts all modifications in
   2.175  the working directory.
   2.176 @@ -169,19 +169,19 @@
   2.177  \item[\hgopt{qpop}{-n}] Pop a patch from the named queue.
   2.178  \end{itemize}
   2.179  
   2.180 -The \hgcmd{qpop} command removes one line from the end of the
   2.181 +The \hgxcmd{mq}{qpop} command removes one line from the end of the
   2.182  \sfilename{status} file for each patch that it pops.
   2.183  
   2.184 -\subsection{\hgcmd{qprev}---print the name of the previous patch}
   2.185 -
   2.186 -The \hgcmd{qprev} command prints the name of the patch in the
   2.187 +\subsection{\hgxcmd{mq}{qprev}---print the name of the previous patch}
   2.188 +
   2.189 +The \hgxcmd{mq}{qprev} command prints the name of the patch in the
   2.190  \sfilename{series} file that comes before the topmost applied patch.
   2.191 -This will become the topmost applied patch if you run \hgcmd{qpop}.
   2.192 -
   2.193 -\subsection{\hgcmd{qpush}---push patches onto the stack}
   2.194 +This will become the topmost applied patch if you run \hgxcmd{mq}{qpop}.
   2.195 +
   2.196 +\subsection{\hgxcmd{mq}{qpush}---push patches onto the stack}
   2.197  \label{sec:mqref:cmd:qpush}
   2.198  
   2.199 -The \hgcmd{qpush} command adds patches onto the applied stack.  By
   2.200 +The \hgxcmd{mq}{qpush} command adds patches onto the applied stack.  By
   2.201  default, it adds only one patch.
   2.202  
   2.203  This command creates a new changeset to represent each applied patch,
   2.204 @@ -191,8 +191,8 @@
   2.205  \begin{itemize}
   2.206  \item The commit date and time zone are the current date and time
   2.207    zone.  Because these data are used to compute the identity of a
   2.208 -  changeset, this means that if you \hgcmd{qpop} a patch and
   2.209 -  \hgcmd{qpush} it again, the changeset that you push will have a
   2.210 +  changeset, this means that if you \hgxcmd{mq}{qpop} a patch and
   2.211 +  \hgxcmd{mq}{qpush} it again, the changeset that you push will have a
   2.212    different identity than the changeset you popped.
   2.213  \item The author is the same as the default used by the \hgcmd{commit}
   2.214    command.
   2.215 @@ -217,17 +217,17 @@
   2.216  \item[\hgopt{qpush}{-n}] Use the named queue if merging while pushing.
   2.217  \end{itemize}
   2.218  
   2.219 -The \hgcmd{qpush} command reads, but does not modify, the
   2.220 +The \hgxcmd{mq}{qpush} command reads, but does not modify, the
   2.221  \sfilename{series} file.  It appends one line to the \hgcmd{status}
   2.222  file for each patch that it pushes.
   2.223  
   2.224 -\subsection{\hgcmd{qrefresh}---update the topmost applied patch}
   2.225 -
   2.226 -The \hgcmd{qrefresh} command updates the topmost applied patch.  It
   2.227 +\subsection{\hgxcmd{mq}{qrefresh}---update the topmost applied patch}
   2.228 +
   2.229 +The \hgxcmd{mq}{qrefresh} command updates the topmost applied patch.  It
   2.230  modifies the patch, removes the old changeset that represented the
   2.231  patch, and creates a new changeset to represent the modified patch.
   2.232  
   2.233 -The \hgcmd{qrefresh} command looks for the following modifications:
   2.234 +The \hgxcmd{mq}{qrefresh} command looks for the following modifications:
   2.235  \begin{itemize}
   2.236  \item Changes to the commit message, i.e.~the text before the first
   2.237    diff header in the patch file, are reflected in the new changeset
   2.238 @@ -240,7 +240,7 @@
   2.239    sources are removed.
   2.240  \end{itemize}
   2.241  
   2.242 -Even if \hgcmd{qrefresh} detects no changes, it still recreates the
   2.243 +Even if \hgxcmd{mq}{qrefresh} detects no changes, it still recreates the
   2.244  changeset that represents the patch.  This causes the identity of the
   2.245  changeset to differ from the previous changeset that identified the
   2.246  patch.
   2.247 @@ -255,43 +255,43 @@
   2.248    description, using text from the given file.
   2.249  \end{itemize}
   2.250  
   2.251 -\subsection{\hgcmd{qrename}---rename a patch}
   2.252 -
   2.253 -The \hgcmd{qrename} command renames a patch, and changes the entry for
   2.254 +\subsection{\hgxcmd{mq}{qrename}---rename a patch}
   2.255 +
   2.256 +The \hgxcmd{mq}{qrename} command renames a patch, and changes the entry for
   2.257  the patch in the \sfilename{series} file.
   2.258  
   2.259 -With a single argument, \hgcmd{qrename} renames the topmost applied
   2.260 +With a single argument, \hgxcmd{mq}{qrename} renames the topmost applied
   2.261  patch.  With two arguments, it renames its first argument to its
   2.262  second.
   2.263  
   2.264 -\subsection{\hgcmd{qrestore}---restore saved queue state}
   2.265 +\subsection{\hgxcmd{mq}{qrestore}---restore saved queue state}
   2.266  
   2.267  XXX No idea what this does.
   2.268  
   2.269 -\subsection{\hgcmd{qsave}---save current queue state}
   2.270 +\subsection{\hgxcmd{mq}{qsave}---save current queue state}
   2.271  
   2.272  XXX Likewise.
   2.273  
   2.274 -\subsection{\hgcmd{qseries}---print the entire patch series}
   2.275 -
   2.276 -The \hgcmd{qseries} command prints the entire patch series from the
   2.277 +\subsection{\hgxcmd{mq}{qseries}---print the entire patch series}
   2.278 +
   2.279 +The \hgxcmd{mq}{qseries} command prints the entire patch series from the
   2.280  \sfilename{series} file.  It prints only patch names, not empty lines
   2.281  or comments.  It prints in order from first to be applied to last.
   2.282  
   2.283 -\subsection{\hgcmd{qtop}---print the name of the current patch}
   2.284 -
   2.285 -The \hgcmd{qtop} prints the name of the topmost currently applied
   2.286 +\subsection{\hgxcmd{mq}{qtop}---print the name of the current patch}
   2.287 +
   2.288 +The \hgxcmd{mq}{qtop} prints the name of the topmost currently applied
   2.289  patch.
   2.290  
   2.291 -\subsection{\hgcmd{qunapplied}---print patches not yet applied}
   2.292 -
   2.293 -The \hgcmd{qunapplied} command prints the names of patches from the
   2.294 +\subsection{\hgxcmd{mq}{qunapplied}---print patches not yet applied}
   2.295 +
   2.296 +The \hgxcmd{mq}{qunapplied} command prints the names of patches from the
   2.297  \sfilename{series} file that are not yet applied.  It prints them in
   2.298  order from the next patch that will be pushed to the last.
   2.299  
   2.300 -\subsection{\hgcmd{qversion}}
   2.301 -
   2.302 -The \hgcmd{qversion} command prints the version of MQ that is in use.
   2.303 +\subsection{\hgxcmd{mq}{qversion}}
   2.304 +
   2.305 +The \hgxcmd{mq}{qversion} command prints the version of MQ that is in use.
   2.306  
   2.307  \subsection{\hgcmd{strip}---remove a revision and descendants}
   2.308  
   2.309 @@ -328,7 +328,7 @@
   2.310  
   2.311  You will often need to edit the \sfilename{series} file by hand, hence
   2.312  the support for comments and empty lines noted above.  For example,
   2.313 -you can comment out a patch temporarily, and \hgcmd{qpush} will skip
   2.314 +you can comment out a patch temporarily, and \hgxcmd{mq}{qpush} will skip
   2.315  over that patch when applying patches.  You can also change the order
   2.316  in which patches are applied by reordering their entries in the
   2.317  \sfilename{series} file.
   2.318 @@ -336,7 +336,7 @@
   2.319  Placing the \sfilename{series} file under revision control is also
   2.320  supported; it is a good idea to place all of the patches that it
   2.321  refers to under revision control, as well.  If you create a patch
   2.322 -directory using the \hgopt{qinit}{-c} option to \hgcmd{qinit}, this
   2.323 +directory using the \hgopt{qinit}{-c} option to \hgxcmd{mq}{qinit}, this
   2.324  will be done for you automatically.
   2.325  
   2.326  \subsection{The \sfilename{status} file}

     3.1 --- a/en/mq.tex	Sun May 27 09:40:12 2007 -0700
     3.2 +++ b/en/mq.tex	Sun May 27 09:41:55 2007 -0700
     3.3 @@ -227,7 +227,7 @@
     3.4  
     3.5  Once the extension is enabled, it will make a number of new commands
     3.6  available.  To verify that the extension is working, you can use
     3.7 -\hgcmd{help} to see if the \hgcmd{qinit} command is now available; see
     3.8 +\hgcmd{help} to see if the \hgxcmd{mq}{qinit} command is now available; see
     3.9  the example in figure~\ref{ex:mq:enabled}.
    3.10  
    3.11  \begin{figure}[ht]
    3.12 @@ -238,10 +238,10 @@
    3.13  
    3.14  You can use MQ with \emph{any} Mercurial repository, and its commands
    3.15  only operate within that repository.  To get started, simply prepare
    3.16 -the repository using the \hgcmd{qinit} command (see
    3.17 +the repository using the \hgxcmd{mq}{qinit} command (see
    3.18  figure~\ref{ex:mq:qinit}).  This command creates an empty directory
    3.19  called \sdirname{.hg/patches}, where MQ will keep its metadata.  As
    3.20 -with many Mercurial commands, the \hgcmd{qinit} command prints nothing
    3.21 +with many Mercurial commands, the \hgxcmd{mq}{qinit} command prints nothing
    3.22  if it succeeds.
    3.23  
    3.24  \begin{figure}[ht]
    3.25 @@ -258,7 +258,7 @@
    3.26  
    3.27  \subsection{Creating a new patch}
    3.28  
    3.29 -To begin work on a new patch, use the \hgcmd{qnew} command.  This
    3.30 +To begin work on a new patch, use the \hgxcmd{mq}{qnew} command.  This
    3.31  command takes one argument, the name of the patch to create.  MQ will
    3.32  use this as the name of an actual file in the \sdirname{.hg/patches}
    3.33  directory, as you can see in figure~\ref{ex:mq:qnew}.
    3.34 @@ -286,7 +286,7 @@
    3.35  \subsection{Refreshing a patch}
    3.36  
    3.37  When you reach a point where you want to save your work, use the
    3.38 -\hgcmd{qrefresh} command (figure~\ref{ex:mq:qnew}) to update the patch
    3.39 +\hgxcmd{mq}{qrefresh} command (figure~\ref{ex:mq:qnew}) to update the patch
    3.40  you are working on.  This command folds the changes you have made in
    3.41  the working directory into your patch, and updates its corresponding
    3.42  changeset to contain those changes.
    3.43 @@ -297,7 +297,7 @@
    3.44    \label{ex:mq:qrefresh}
    3.45  \end{figure}
    3.46  
    3.47 -You can run \hgcmd{qrefresh} as often as you like, so it's a good way
    3.48 +You can run \hgxcmd{mq}{qrefresh} as often as you like, so it's a good way
    3.49  to ``checkpoint'' your work.  Refresh your patch at an opportune
    3.50  time; try an experiment; and if the experiment doesn't work out,
    3.51  \hgcmd{revert} your modifications back to the last time you refreshed.
    3.52 @@ -311,7 +311,7 @@
    3.53  \subsection{Stacking and tracking patches}
    3.54  
    3.55  Once you have finished working on a patch, or need to work on another,
    3.56 -you can use the \hgcmd{qnew} command again to create a new patch.
    3.57 +you can use the \hgxcmd{mq}{qnew} command again to create a new patch.
    3.58  Mercurial will apply this patch on top of your existing patch.  See
    3.59  figure~\ref{ex:mq:qnew2} for an example.  Notice that the patch
    3.60  contains the changes in our prior patch as part of its context (you
    3.61 @@ -323,24 +323,24 @@
    3.62    \label{ex:mq:qnew2}
    3.63  \end{figure}
    3.64  
    3.65 -So far, with the exception of \hgcmd{qnew} and \hgcmd{qrefresh}, we've
    3.66 +So far, with the exception of \hgxcmd{mq}{qnew} and \hgxcmd{mq}{qrefresh}, we've
    3.67  been careful to only use regular Mercurial commands.  However, MQ
    3.68  provides many commands that are easier to use when you are thinking
    3.69  about patches, as illustrated in figure~\ref{ex:mq:qseries}:
    3.70  
    3.71  \begin{itemize}
    3.72 -\item The \hgcmd{qseries} command lists every patch that MQ knows
    3.73 +\item The \hgxcmd{mq}{qseries} command lists every patch that MQ knows
    3.74    about in this repository, from oldest to newest (most recently
    3.75    \emph{created}).
    3.76 -\item The \hgcmd{qapplied} command lists every patch that MQ has
    3.77 +\item The \hgxcmd{mq}{qapplied} command lists every patch that MQ has
    3.78    \emph{applied} in this repository, again from oldest to newest (most
    3.79    recently applied).
    3.80  \end{itemize}
    3.81  
    3.82  \begin{figure}[ht]
    3.83    \interaction{mq.tutorial.qseries}
    3.84 -  \caption{Understanding the patch stack with \hgcmd{qseries} and
    3.85 -    \hgcmd{qapplied}}
    3.86 +  \caption{Understanding the patch stack with \hgxcmd{mq}{qseries} and
    3.87 +    \hgxcmd{mq}{qapplied}}
    3.88    \label{ex:mq:qseries}
    3.89  \end{figure}
    3.90  
    3.91 @@ -353,7 +353,7 @@
    3.92  An \emph{applied} patch has a corresponding changeset in the
    3.93  repository, and the effects of the patch and changeset are visible in
    3.94  the working directory.  You can undo the application of a patch using
    3.95 -the \hgcmd{qpop} command.  MQ still \emph{knows about}, or manages, a
    3.96 +the \hgxcmd{mq}{qpop} command.  MQ still \emph{knows about}, or manages, a
    3.97  popped patch, but the patch no longer has a corresponding changeset in
    3.98  the repository, and the working directory does not contain the changes
    3.99  made by the patch.  Figure~\ref{fig:mq:stack} illustrates the
   3.100 @@ -366,13 +366,13 @@
   3.101    \label{fig:mq:stack}
   3.102  \end{figure}
   3.103  
   3.104 -You can reapply an unapplied, or popped, patch using the \hgcmd{qpush}
   3.105 +You can reapply an unapplied, or popped, patch using the \hgxcmd{mq}{qpush}
   3.106  command.  This creates a new changeset to correspond to the patch, and
   3.107  the patch's changes once again become present in the working
   3.108 -directory.  See figure~\ref{ex:mq:qpop} for examples of \hgcmd{qpop}
   3.109 -and \hgcmd{qpush} in action.  Notice that once we have popped a patch
   3.110 -or two patches, the output of \hgcmd{qseries} remains the same, while
   3.111 -that of \hgcmd{qapplied} has changed.
   3.112 +directory.  See figure~\ref{ex:mq:qpop} for examples of \hgxcmd{mq}{qpop}
   3.113 +and \hgxcmd{mq}{qpush} in action.  Notice that once we have popped a patch
   3.114 +or two patches, the output of \hgxcmd{mq}{qseries} remains the same, while
   3.115 +that of \hgxcmd{mq}{qapplied} has changed.
   3.116  
   3.117  \begin{figure}[ht]
   3.118    \interaction{mq.tutorial.qpop}
   3.119 @@ -382,10 +382,10 @@
   3.120  
   3.121  \subsection{Pushing and popping many patches}
   3.122  
   3.123 -While \hgcmd{qpush} and \hgcmd{qpop} each operate on a single patch at
   3.124 +While \hgxcmd{mq}{qpush} and \hgxcmd{mq}{qpop} each operate on a single patch at
   3.125  a time by default, you can push and pop many patches in one go.  The
   3.126 -\hgopt{qpush}{-a} option to \hgcmd{qpush} causes it to push all
   3.127 -unapplied patches, while the \hgopt{qpop}{-a} option to \hgcmd{qpop}
   3.128 +\hgopt{qpush}{-a} option to \hgxcmd{mq}{qpush} causes it to push all
   3.129 +unapplied patches, while the \hgopt{qpop}{-a} option to \hgxcmd{mq}{qpop}
   3.130  causes it to pop all applied patches.  (For some more ways to push and
   3.131  pop many patches, see section~\ref{sec:mq:perf} below.)
   3.132  
   3.133 @@ -401,7 +401,7 @@
   3.134  anything, and fail if they find any modifications.  They do this to
   3.135  ensure that you won't lose any changes that you have made, but not yet
   3.136  incorporated into a patch.  Figure~\ref{ex:mq:add} illustrates this;
   3.137 -the \hgcmd{qnew} command will not create a new patch if there are
   3.138 +the \hgxcmd{mq}{qnew} command will not create a new patch if there are
   3.139  outstanding changes, caused in this case by the \hgcmd{add} of
   3.140  \filename{file3}.
   3.141  
   3.142 @@ -422,7 +422,7 @@
   3.143  
   3.144  \subsection{Working on several patches at once}
   3.145  
   3.146 -The \hgcmd{qrefresh} command always refreshes the \emph{topmost}
   3.147 +The \hgxcmd{mq}{qrefresh} command always refreshes the \emph{topmost}
   3.148  applied patch.  This means that you can suspend work on one patch (by
   3.149  refreshing it), pop or push to make a different patch the top, and
   3.150  work on \emph{that} patch for a while.
   3.151 @@ -433,9 +433,9 @@
   3.152  top of the first---changes the user interface to use the code you just
   3.153  added to the core.  If you notice a bug in the core while you're
   3.154  working on the UI patch, it's easy to fix the core.  Simply
   3.155 -\hgcmd{qrefresh} the UI patch to save your in-progress changes, and
   3.156 -\hgcmd{qpop} down to the core patch.  Fix the core bug,
   3.157 -\hgcmd{qrefresh} the core patch, and \hgcmd{qpush} back to the UI
   3.158 +\hgxcmd{mq}{qrefresh} the UI patch to save your in-progress changes, and
   3.159 +\hgxcmd{mq}{qpop} down to the core patch.  Fix the core bug,
   3.160 +\hgxcmd{mq}{qrefresh} the core patch, and \hgxcmd{mq}{qpush} back to the UI
   3.161  patch to continue where you left off.
   3.162  
   3.163  \section{More about patches}
   3.164 @@ -487,11 +487,11 @@
   3.165  
   3.166  If you receive a patch from someone that you want to add to your patch
   3.167  queue, and the patch needs a strip count other than one, you cannot
   3.168 -just \hgcmd{qimport} the patch, because \hgcmd{qimport} does not yet
   3.169 +just \hgxcmd{mq}{qimport} the patch, because \hgxcmd{mq}{qimport} does not yet
   3.170  have a \texttt{-p} option (see~\bug{311}).  Your best bet is to
   3.171 -\hgcmd{qnew} a patch of your own, then use \cmdargs{patch}{-p\emph{N}}
   3.172 +\hgxcmd{mq}{qnew} a patch of your own, then use \cmdargs{patch}{-p\emph{N}}
   3.173  to apply their patch, followed by \hgcmd{addremove} to pick up any
   3.174 -files added or removed by the patch, followed by \hgcmd{qrefresh}.
   3.175 +files added or removed by the patch, followed by \hgxcmd{mq}{qrefresh}.
   3.176  This complexity may become unnecessary; see~\bug{311} for details.
   3.177  \subsection{Strategies for applying a patch}
   3.178  
   3.179 @@ -557,7 +557,7 @@
   3.180  be completely successful, these inexact techniques naturally leave
   3.181  open the possibility of corrupting the patched file.  The most common
   3.182  cases typically involve applying a patch twice, or at an incorrect
   3.183 -location in the file.  If \command{patch} or \hgcmd{qpush} ever
   3.184 +location in the file.  If \command{patch} or \hgxcmd{mq}{qpush} ever
   3.185  mentions an offset or fuzz factor, you should make sure that the
   3.186  modified files are correct afterwards.  
   3.187  
   3.188 @@ -573,7 +573,7 @@
   3.189  
   3.190  \subsection{Handling rejection}
   3.191  
   3.192 -If \hgcmd{qpush} fails to apply a patch, it will print an error
   3.193 +If \hgxcmd{mq}{qpush} fails to apply a patch, it will print an error
   3.194  message and exit.  If it has left \sfilename{.rej} files behind, it is
   3.195  usually best to fix up the rejected hunks before you push more patches
   3.196  or do any further work.
   3.197 @@ -627,24 +627,24 @@
   3.198  \hgcmdargs{qpush}{\hgopt{qpush}{-a}} all 1,738 patches in 3.5 minutes,
   3.199  and \hgcmdargs{qpop}{\hgopt{qpop}{-a}} them all in 30 seconds.  (On a
   3.200  newer laptop, the time to push all patches dropped to two minutes.)  I
   3.201 -could \hgcmd{qrefresh} one of the biggest patches (which made 22,779
   3.202 +could \hgxcmd{mq}{qrefresh} one of the biggest patches (which made 22,779
   3.203  lines of changes to 287 files) in 6.6 seconds.
   3.204  
   3.205  Clearly, MQ is well suited to working in large trees, but there are a
   3.206  few tricks you can use to get the best performance of it.
   3.207  
   3.208  First of all, try to ``batch'' operations together.  Every time you
   3.209 -run \hgcmd{qpush} or \hgcmd{qpop}, these commands scan the working
   3.210 +run \hgxcmd{mq}{qpush} or \hgxcmd{mq}{qpop}, these commands scan the working
   3.211  directory once to make sure you haven't made some changes and then
   3.212 -forgotten to run \hgcmd{qrefresh}.  On a small tree, the time that
   3.213 +forgotten to run \hgxcmd{mq}{qrefresh}.  On a small tree, the time that
   3.214  this scan takes is unnoticeable.  However, on a medium-sized tree
   3.215  (containing tens of thousands of files), it can take a second or more.
   3.216  
   3.217 -The \hgcmd{qpush} and \hgcmd{qpop} commands allow you to push and pop
   3.218 +The \hgxcmd{mq}{qpush} and \hgxcmd{mq}{qpop} commands allow you to push and pop
   3.219  multiple patches at a time.  You can identify the ``destination
   3.220 -patch'' that you want to end up at.  When you \hgcmd{qpush} with a
   3.221 +patch'' that you want to end up at.  When you \hgxcmd{mq}{qpush} with a
   3.222  destination specified, it will push patches until that patch is at the
   3.223 -top of the applied stack.  When you \hgcmd{qpop} to a destination, MQ
   3.224 +top of the applied stack.  When you \hgxcmd{mq}{qpop} to a destination, MQ
   3.225  will pop patches until the destination patch is at the top.
   3.226  
   3.227  You can identify a destination patch using either the name of the
   3.228 @@ -668,7 +668,7 @@
   3.229  repository, and finally \hgcmdargs{qpush}{\hgopt{qpop}{-a}} your
   3.230  patches again.  MQ will stop pushing any time it runs across a patch
   3.231  that fails to apply during conflicts, allowing you to fix your
   3.232 -conflicts, \hgcmd{qrefresh} the affected patch, and continue pushing
   3.233 +conflicts, \hgxcmd{mq}{qrefresh} the affected patch, and continue pushing
   3.234  until you have fixed your entire stack.
   3.235  
   3.236  This approach is easy to use and works well if you don't expect
   3.237 @@ -700,13 +700,13 @@
   3.238    \hgcmdargs{update}{\hgopt{update}{-C}} to override the patches you
   3.239    have pushed.
   3.240  \item Merge all patches using \hgcmdargs{qpush}{\hgopt{qpush}{-m}
   3.241 -    \hgopt{qpush}{-a}}.  The \hgopt{qpush}{-m} option to \hgcmd{qpush}
   3.242 +    \hgopt{qpush}{-a}}.  The \hgopt{qpush}{-m} option to \hgxcmd{mq}{qpush}
   3.243    tells MQ to perform a three-way merge if the patch fails to apply.
   3.244  \end{enumerate}
   3.245  
   3.246  During the \hgcmdargs{qpush}{\hgopt{qpush}{-m}}, each patch in the
   3.247  \sfilename{series} file is applied normally.  If a patch applies with
   3.248 -fuzz or rejects, MQ looks at the queue you \hgcmd{qsave}d, and
   3.249 +fuzz or rejects, MQ looks at the queue you \hgxcmd{mq}{qsave}d, and
   3.250  performs a three-way merge with the corresponding changeset.  This
   3.251  merge uses Mercurial's normal merge machinery, so it may pop up a GUI
   3.252  merge tool to help you to resolve problems.
   3.253 @@ -725,7 +725,7 @@
   3.254  
   3.255  MQ commands that work with patches let you refer to a patch either by
   3.256  using its name or by a number.  By name is obvious enough; pass the
   3.257 -name \filename{foo.patch} to \hgcmd{qpush}, for example, and it will
   3.258 +name \filename{foo.patch} to \hgxcmd{mq}{qpush}, for example, and it will
   3.259  push patches until \filename{foo.patch} is applied.  
   3.260  
   3.261  As a shortcut, you can refer to a patch using both a name and a
   3.262 @@ -734,7 +734,7 @@
   3.263  after \texttt{bar.patch}''.
   3.264  
   3.265  Referring to a patch by index isn't much different.  The first patch
   3.266 -printed in the output of \hgcmd{qseries} is patch zero (yes, it's one
   3.267 +printed in the output of \hgxcmd{mq}{qseries} is patch zero (yes, it's one
   3.268  of those start-at-zero counting systems); the second is patch one; and
   3.269  so on
   3.270  
   3.271 @@ -789,7 +789,7 @@
   3.272  one place.
   3.273  
   3.274  \begin{itemize}
   3.275 -\item Normally, when you \hgcmd{qpop} a patch and \hgcmd{qpush} it
   3.276 +\item Normally, when you \hgxcmd{mq}{qpop} a patch and \hgxcmd{mq}{qpush} it
   3.277    again, the changeset that represents the patch after the pop/push
   3.278    will have a \emph{different identity} than the changeset that
   3.279    represented the hash beforehand.  See
   3.280 @@ -811,7 +811,7 @@
   3.281  This presents the interesting possibility of managing the contents of
   3.282  the patch directory as a Mercurial repository in its own right.  This
   3.283  can be a useful way to work.  For example, you can work on a patch for
   3.284 -a while, \hgcmd{qrefresh} it, then \hgcmd{commit} the current state of
   3.285 +a while, \hgxcmd{mq}{qrefresh} it, then \hgcmd{commit} the current state of
   3.286  the patch.  This lets you ``roll back'' to that version of the patch
   3.287  later on.
   3.288  
   3.289 @@ -833,7 +833,7 @@
   3.290  
   3.291  MQ helps you to work with the \sdirname{.hg/patches} directory as a
   3.292  repository; when you prepare a repository for working with patches
   3.293 -using \hgcmd{qinit}, you can pass the \hgopt{qinit}{-c} option to
   3.294 +using \hgxcmd{mq}{qinit}, you can pass the \hgopt{qinit}{-c} option to
   3.295  create the \sdirname{.hg/patches} directory as a Mercurial repository.
   3.296  
   3.297  \begin{note}
   3.298 @@ -851,7 +851,7 @@
   3.299  directory is a repository, it will automatically \hgcmd{add} every
   3.300  patch that you create and import.
   3.301  
   3.302 -Finally, MQ provides a shortcut command, \hgcmd{qcommit}, that runs
   3.303 +Finally, MQ provides a shortcut command, \hgxcmd{mq}{qcommit}, that runs
   3.304  \hgcmd{commit} in the \sdirname{.hg/patches} directory.  This saves
   3.305  some cumbersome typing.
   3.306  
   3.307 @@ -911,15 +911,15 @@
   3.308  \filename{rework-device-alloc.patch}, because it will immediately give
   3.309  you a hint what the purpose of the patch is.  Long names shouldn't be
   3.310  a problem; you won't be typing the names often, but you \emph{will} be
   3.311 -running commands like \hgcmd{qapplied} and \hgcmd{qtop} over and over.
   3.312 +running commands like \hgxcmd{mq}{qapplied} and \hgxcmd{mq}{qtop} over and over.
   3.313  Good naming becomes especially important when you have a number of
   3.314  patches to work with, or if you are juggling a number of different
   3.315  tasks and your patches only get a fraction of your attention.
   3.316  
   3.317 -Be aware of what patch you're working on.  Use the \hgcmd{qtop}
   3.318 +Be aware of what patch you're working on.  Use the \hgxcmd{mq}{qtop}
   3.319  command and skim over the text of your patches frequently---for
   3.320  example, using \hgcmdargs{tip}{\hgopt{tip}{-p}})---to be sure of where
   3.321 -you stand.  I have several times worked on and \hgcmd{qrefresh}ed a
   3.322 +you stand.  I have several times worked on and \hgxcmd{mq}{qrefresh}ed a
   3.323  patch other than the one I intended, and it's often tricky to migrate
   3.324  changes into the right patch after making them in the wrong one.
   3.325  
   3.326 @@ -960,14 +960,14 @@
   3.327  \subsection{Combining entire patches}
   3.328  \label{sec:mq:combine}
   3.329  
   3.330 -MQ provides a command, \hgcmd{qfold} that lets you combine entire
   3.331 +MQ provides a command, \hgxcmd{mq}{qfold} that lets you combine entire
   3.332  patches.  This ``folds'' the patches you name, in the order you name
   3.333  them, into the topmost applied patch, and concatenates their
   3.334  descriptions onto the end of its description.  The patches that you
   3.335  fold must be unapplied before you fold them.
   3.336  
   3.337  The order in which you fold patches matters.  If your topmost applied
   3.338 -patch is \texttt{foo}, and you \hgcmd{qfold} \texttt{bar} and
   3.339 +patch is \texttt{foo}, and you \hgxcmd{mq}{qfold} \texttt{bar} and
   3.340  \texttt{quux} into it, you will end up with a patch that has the same
   3.341  effect as if you applied first \texttt{foo}, then \texttt{bar},
   3.342  followed by \texttt{quux}.
   3.343 @@ -983,8 +983,8 @@
   3.344  out of one patch, concatenating its output onto the end of the patch
   3.345  you want to merge into.  You usually won't need to modify the patch
   3.346  you've merged the changes from.  Instead, MQ will report some rejected
   3.347 -hunks when you \hgcmd{qpush} it (from the hunks you moved into the
   3.348 -other patch), and you can simply \hgcmd{qrefresh} the patch to drop
   3.349 +hunks when you \hgxcmd{mq}{qpush} it (from the hunks you moved into the
   3.350 +other patch), and you can simply \hgxcmd{mq}{qrefresh} the patch to drop
   3.351  the duplicate hunks.
   3.352  
   3.353  If you have a patch that has multiple hunks modifying a file, and you