[PATCH 1 of 1] mq/qpop: option to keep current working directory contents and state

[Giorgos Keramidas]

On Tue, 03 Nov 2009 18:53:28 +0100, Martin Geisler <mg at lazybytes.net> wrote:
> Matt Mackall <mpm at selenic.com> writes:
>> On Tue, 2009-11-03 at 17:46 +0100, Sune Foldager wrote:
>>> # HG changeset patch
>>> # User Sune Foldager <cryo at cyanite.org>
>>> # Date 1257266773 -3600
>>> # Node ID 0ec6fe902e1abd4f5f8faff0e35516a13651ff26
>>> # Parent  bd3af545c7c6f7fb66c9377259316220d329282d
>>> mq/qpop: option to keep current working directory contents and state
>>>
>>> This allows you to qpop a patch, keeping its contents in the working directory,
>>> and then qdelete it subsequently. It can also, in connection with qimport, be used
>>> in general to "return committed changes to the working directory".
>>
>> That's weird. It's sort of an inverse revert. There are a bunch of
>> other fairly obvious ways to do this fairly unusual operation, so I'm
>> not sure if it makes sense to add a new feature for it.
>
> I agree that it's a bit unusual, but it answer a question I've seen on
> IRC a couple of times: how do I get my changes out of mq. Without it, it
> seems to people that the changes are "trapped" in mq :-)
>
>> or:
>>
>> hg qpop
>> hg import --no-commit .hg/patches/`hg qnext`
>
> That last recipe is good!

I've also used the following a few times:

    hg qrefresh -X '**'
    hg qpop -f

The patch is still left in mq, but it's empty and can be deleted or
one can refresh _parts_ of the working directory state into the patch
(i.e. to split a large part in two smaller ones).

I am not sure if we need a new option for this, but it doesn't sound
harmful to have one either.