Confirm, emeritus
792
edits
Changes
no edit summary
* <tt>hg update tip</tt> to jump to the latest tip that you just pulled from the CVS repo, and then use the transplant extension to move your patch(es) over from previous change sets. e.g. <tt>hg transplant 255</tt> to take changeset 255 and apply it to the current working dir. Transplanting in this way is very similar to <tt>hg export 255 > foo.patch</tt> followed by a <tt>patch -p1 < foo.patch</tt>, <tt>hg commit -m "orig commit message"</tt>, except that it will stop and ask you to fix up conflicts.
== Managing patches ==
This is a brief introduction to MQ, the Mercurial Queues extension. You must explicitly enable it by adding
hgext.mq =
to the <tt><nowiki>[extensions]</nowiki></tt> section of ~/.hgrc or Mercurial.ini. You'll know whether it's enabled if <tt>hg qapplied</tt> doesn't return an error about an unknown command.
A much more comprehensive overview is available in [http://hgbook.red-bean.com/hgbookch12.html#x16-26500012 the MQ chapter of the hg book].
=== Creating a new patch ===
% cd mozilla
% hg qnew 369012-fix-bad-crash
% <nowiki>[hack hack hack]</nowiki>
% hg qrefresh
The above initializes a new patch named "369012-fix-bad-crash" (you can use any valid filename that you wish, though I tend to prefix things with the bug number... I use xxxxxx if no bug has been filed yet). After you make your changes, <tt>hg qrefresh</tt> updates the topmost patch with the current diff from the working directory.
You can also create a patch after the fact, incorporating any outstanding changes in the working directory into it. This is the way that I tend to work:
% cd mozilla
% <nowiki>[hack hack hack]</nowiki>
% hg qnew -f 369012-fix-bad-crash
The <tt>-f</tt> informs qnew to take the outstanding changes and make them part of the patch; otherwise, qnew will complain about outstanding changes and refuse to make a new patch.
After either of these steps:
% hg qapplied
369012-fix-bad-crash
% hg qtop
369012-fix-bad-crash
<tt>qtop</tt> will show you the current topmost patch, and <tt>qapplied</tt> will show you the list of applied patches. Let's say you make another patch:
% ... make changes ...
% hg qnew -f 301123-new-feature
% hg qapplied
369012-fix-bad-crash
301123-new-feature
% hg qtop
301123-new-feature
The <tt>301123-new-feature</tt> patch is created <i>relative to</i> the previous patch for 369012. This is important in case you ever want to reorder patches, or if you need to submit patches for review that have dependencies on other patches.
You can pop the topmost patch from your working directory:
% hg qpop
Now at: 369012-fix-bad-crash
Note that these patches live as normal patch files in the .hg/patches directory; this is what I use for submitting patches for review. The order in which they're applied is just a text file in .hg/patches/series -- <i>but don't edit the order of currently applied patches, because bad things will happen.</i>
Note that while patches are applied, they show up as real changesets in the repository:
% hg qapplied
one
two
% hg log -l 3
3[qtip,tip,two] c1e6c90c12ad 2007-07-31 15:20 -0700 vladimir
imported patch two
2[qbase,one] 2ba59c979503 2007-07-31 15:18 -0700 vladimir
[mq]: one
1[qparent] 587167de96c1 2007-07-31 14:42 -0700 vladimir
Add mystery message to README.txt
This is why it's important to <tt>qpop -a</tt> to remove all patches from the stack before doing any pushing or pulling from your working repository. Otherwise, the remote doesn't have any idea of your patches, and these will just show up as changesets.
When you're ready to commit a patch, the easiest thing is:
% hg qpush
Now at: one
% hg qapplied
one
% hg qrm -r one
<tt>qrm -r <i>patchname</i></tt> tells mq to stop managing the patch named <i>patchname</i> which must a) be applied; and b) be the bottommost patch on the stack. At that point, that patch is just a normal changeset, and you can proceed with the "committing to CVS instructions".
Some other useful commands: <tt>hg qdiff</tt> will show you the diff between your working dir and the previous patch; this is different from <tt>hg diff</tt>, which will show you the diff between your working dir <i>and the last time you refreshed the topmost patch</i>. Both are useful. You can rename patches using <tt>hg qrename</tt>, e.g. to give a patch a bug number. You can also give a patch a commit message, either at <tt>qnew</tt> time using -m, or at <tt>qrefresh</tt> time, also using -m.
