[PATCH RFC] mq: support "qimport --existing --name renametothis thatexistingpatch"

[Nicolas Dumazet]

2010/7/21 timeless <timeless at gmail.com>:
> On Wed, Jul 21, 2010 at 3:02 PM, Johan Samyn <johan.samyn at gmail.com> wrote:
>> 2010/7/21 Martin Geisler <mg at aragost.com>
>>>
>>> Nicolas Dumazet <nicdumz at gmail.com> writes:
>>>
>>> > # HG changeset patch
>>> > # User Nicolas Dumazet <nicdumz.commits at gmail.com>
>>> > # Date 1279680789 -32400
>>> > # Node ID 6e5678b960329674539868ecf6eaf102979f4464
>>> > # Parent  36310766229b03fde600f54503bd11cbcc0e6d74
>>> > mq: support "qimport --existing --name renametothis thatexistingpatch"
>>>
>>> That is a nice idea.
>>
>> I agree. Only ... such reversed-order-things always give me the shivers.
>> IMHO it should become "qimport --existing --rename thatexistingpatch
>> tothisnewpatch".
>> Much more natural/intuitive. But that would require a new option (--rename),
>> which is not obvious I suppose ? Just my 2cents :).
>
> hg qimport [-e] [-n NAME] [-f] [-g] [-P] [-r REV]... FILE...
>
>  -e --existing     import file in patch directory
>  -n --name NAME    name of patch file
>
> i think it's reasonable to expect this to just work today:
>
> qimport -e patch -n newname
>
> that would require a bit of magic to the help and stuff, but....

Knowing that -e is --existing, and -n is --name, what you're
suggesting just works (tm) after my patch.
I think that order of arguments does not matter: -e does not expect
parameter, so all of

qimport -e patch -n newname
qimport -e -n newname patch
qimport patch -n newname -e
qimport patch -e -n newname
qimport -n newname -e patch
qimport -n newname patch -e

[should] have the same effect (tested some, not all; the patch could
be updated to test all cases if deemed necessary)

We can agree to agree :)

-Nicolas.

> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>



-- 
Nicolas Dumazet — NicDumZ