Non-linear patch queues

Sebastian Unger sebastian.unger at taitradio.com
Thu Jul 3 21:29:29 UTC 2014


Hi Guys,

First of all, thank you for a very cool and powerful tool. I have been
using mercurial for almost three years now, switching from SVN and I must
say, I love it. I particularly love patch queues. I have no idea how I used
to do major refactorings before PQs.

Over the last 6 months I have been using PQs very intensively as I'm going
through a major refactoring and in so doing I found that Mercurial could be
even more awesome if it had this feature:


   1. -e can be applied to qpush even when pushing patches other than the
   first. When using -a -e it is applied to all.
   2. When a patch is pushed with -e, it is applied to the node recorded as
   its parent *if *it exists in the repo or the current qtip if it isn't.
   3. When a patch is pushed without -e, it is applied on top of the
   current changeset even if it is not qtip.
   4. qtip is always the changeset corresponding to the last pushed patch.
   5. When popping, changesets are stripped from whereever they are (they
   may no longer be in a single sequence of changesets, but the qtip still
   cannot have any children according to these rules).
   6. Add a new command qlinearize (or whatever seems a suitable name) that
   for each applied patch except qbase, rebases that changeset (along with its
   children, if any) onto the previous applied patch in the series. The result
   should be a single linear sequence of changesets again.

Rationale:
I find myself quite often going up and down the patch queue and doing
refactorings in between. Once I have done a refactoring and created a
patch, I then of course find that the remaining patches in the queue do not
apply any more. So far, the easiest way I have found for dealing with this
situation is the following steps:

   - Make sure the PQ is committed (I use versioned PQs) and everything is
   pushed
   - qgo to the newly added refactoring patch
   - qfin -a
   - up -r .^
   - qpu -a
   - revert --all --mq
   - rebase -s qbase -d <node that has the refactoring>
   - qpo -a
   - strip -r 'draft()'

These steps make a lot of assumptions and are brittle (the order is
crucial). With the added feature above, mercurial would do all of that
automatically.

Let me know what you think.

BTW, I'm running Ubuntu saucy with mercurial 2.6.3. My apologies if there
is already a better way for doing this in a later version of HG.

Cheers,
-- 
*Sebastian Unger*
*Senior Software Engineer*
Tait Communications
Email: sebastian.unger at taitradio.com <sebastian.unger at taitradio.com>


www.taitradio.com

-- 

------------------------------
This email, including any attachments, is only for the intended recipient. 
It is subject to copyright, is confidential and may be the subject of legal 
or other privilege, none of which is waived or lost by reason of this 
transmission.
If you are not an intended recipient, you may not use, disseminate, 
distribute or reproduce such email, any attachments, or any part thereof. 
If you have received a message in error, please notify the sender 
immediately and erase all copies of the message and any attachments.
Unfortunately, we cannot warrant that the email has not been altered or 
corrupted during transmission nor can we guarantee that any email or any 
attachments are free from computer viruses or other conditions which may 
damage or interfere with recipient data, hardware or software. The 
recipient relies upon its own procedures and assumes all risk of use and of 
opening any attachments.
------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20140704/159e68e0/attachment-0002.html>


More information about the Mercurial mailing list