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

Johan Samyn johan.samyn at gmail.com
Wed Jul 21 10:07:46 CDT 2010


2010/7/21 Johan Samyn <johan.samyn at gmail.com>

> 2010/7/21 Johan Samyn <johan.samyn at gmail.com>
>
> 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....
>>>
>>
>> Aah now I see. Guess I'll have to learn not to react to the subject of the
>> mail only, and also look into the patch itself (and try some things out
>> first for myself). Sorry for adding unnecessary noise to this thread.
>> So, I just tried the new patch here, and it seems to work fine. I noticed
>> the patchfile itself is correctly renamed, and the new name added to the
>> series file. But the series file still contains the old patchname too, while
>> there is no corresponding patchfile for it anymore. Is that intentionally ?
>> -- Johan
>>
>> I forgot to add the output of the 'apply all' after doing the 'qimport
> -name' with the new patch :
> {{{
> applying newrun
> unable to read _run.py
> applying _run.py
> now at: newrun
> [command returned code 1 Wed Jul 21 16:19:59 2010]
> }}}
> This clearly shows the non-existence of the old patchfile.
>
> The fact that the name of the old patch is still in the series file, but
> cannot be applied anymore, also causes TortoiseHg not to enable it's unapply
> buttons after applying such a series files.
> -- Johan
>
> (Ouch, this is becoming the chronicle of a little self-education.) There is
nothing wrong with the patch Nicolas sent in. I was trying it out on an
existing mq patchfile, instead of using qimport for what it was really
meant. When trying that out everything went fine of course.
-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100721/2d4607b8/attachment.htm>


More information about the Mercurial-devel mailing list