RFE: hg import --bypass target should be customizable

[Marc Strapetz]

>> This means, that the working tree has to be reset temporarily what is
>> usually no problem, but could be in case of file system locks. This is
>> what I'm trying to avoid.
> 
> Ah I see. Yes even without filesystem locks this can temporarily
> confuse Eclipse if an affected file is currently open so I would like
> to see a clean way to do this too.

Using the "import --bypass" and its dir-less patcher should not touch
the working directory, however I just noticed that it will fail in case
of file system locks, too, what might be a problem of
"ui.merge=internal:local" merger:

(1) have changeset C1, with parents P1(P2)

(2) commit what should be amended as separate changeset C2

(3) diff --git -r P1 -r C2  > patch.diff

(4) hg import --bypass-parents P1(P2) < patch.diff
    # functionality not yet present, but should
    # give amended commit at tip with appropriate
    # parents set

(5) hg strip --keep C1
    # will move working tree to P1

(6) hg update --config ui.merge=internal:local tip

Now, tip revision is identical to revision C2 and local modifications
shouldn't matter due to "ui.merge=internal:local" merger. However, when
having a modified file locked (on Windows), I still get an "abort:
Permission denied".

Also, in step (5) we will lose scheduling of added and removed files.
However, dirstate can easily be saved and restored after (6).

As we know that (5) + (6) is basically a no-op, we could alternatively
change the working directory anchor to our desired tip changeset
directly in the dirstate ... but I'm not entirely sure if that hack
would work and probably no one here would like to confirm, even if it
actually does ;-)

--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com






On 23.11.2011 19:40, John Peberdy wrote:
> On Wed, Nov 23, 2011 at 1:28 PM, Marc Strapetz
> <marc.strapetz at syntevo.com> wrote:
>>> In MercurialEclipse this is done with mq commands.
>>>
>>> /**
>>>          * Amend adds the changes in the selected files to the parent
>>> changeset. qrefresh isn't used
>>>          * generally because when it fails (eg inconsistent line
>>> endings) then programatically restoring
>>>          * state is hard. Instead the parent is qimported (a), the
>>> selected files are qnew'd (b), if
>>>          * still dirty remaining files are added to a 2nd qnew'd patch
>>> (c). Then a and b are folded and
>>>          * c is applied and then stripped. This also works around the
>>> problem of qrefresh unexpectedly
>>>          * adding changes to a file if changes in that file are
>>> already in the patch.
>>> */
>>
>> Thanks for pointing out. The disadvantage of this approach is:
>>
>>> if still dirty remaining files are added to a 2nd qnew'd patch
>>> (c).
>>
>> This means, that the working tree has to be reset temporarily what is
>> usually no problem, but could be in case of file system locks. This is
>> what I'm trying to avoid.
> 
> Ah I see. Yes even without filesystem locks this can temporarily
> confuse Eclipse if an affected file is currently open so I would like
> to see a clean way to do this too.
> 
>>
>> --
>> Best regards,
>> Marc Strapetz
>> =============
>> syntevo GmbH
>> http://www.syntevo.com
>> http://blog.syntevo.com
>>
>>
>>
>>
>>
>>
>>
>> On 23.11.2011 18:10, John Peberdy wrote:
>>> On Wed, Nov 23, 2011 at 10:22 AM, Marc Strapetz
>>> <marc.strapetz at syntevo.com> wrote:
>>>> On 23.11.2011 15:34, Patrick Mézard wrote:
>>>>> Le 22/11/11 18:51, Marc Strapetz a écrit :
>>>>>> I'm trying to import a self-created patch into an existing
>>>>>> Mercurial repository with "hg import". Goal is to not touch the
>>>>>> working copy, so I'm using --bypass. Unfortunately, --bypass will
>>>>>> always use the working copy parent which is in general not the
>>>>>> target changeset to which the patch should be applied. --exact
>>>>>> would allow to specify the target "Parent" in the patch, but
>>>>>> unfortunately it performs a final check whether "Node ID" from the
>>>>>> patch matches resulting changeset ID, which isn't the case because
>>>>>> it's self-created and it would be (too) hard to calculate the
>>>>>> correct SHA.
>>>>>
>>>>> Are you writing a mercurial extension?
>>>>
>>>> No. I'm looking for a robust sequence of commands to "amend" a commit
>>>> which can be executed from within a GUI client. I haven't considered to
>>>> do that by a separate extension, but only by standard Mercurial
>>>> functionality (including default extensions).
>>>
>>> In MercurialEclipse this is done with mq commands.
>>>
>>> /**
>>>          * Amend adds the changes in the selected files to the parent
>>> changeset. qrefresh isn't used
>>>          * generally because when it fails (eg inconsistent line
>>> endings) then programatically restoring
>>>          * state is hard. Instead the parent is qimported (a), the
>>> selected files are qnew'd (b), if
>>>          * still dirty remaining files are added to a 2nd qnew'd patch
>>> (c). Then a and b are folded and
>>>          * c is applied and then stripped. This also works around the
>>> problem of qrefresh unexpectedly
>>>          * adding changes to a file if changes in that file are
>>> already in the patch.
>>> */
>>>
>>>  com.vectrace.MercurialEclipse.dialogs.CommitDialog.performAmend(String,
>>> ChangeSet)
>>>
>>> http://code.google.com/a/eclipselabs.org/p/mercurialeclipse/source/browse/plugin/src/com/vectrace/MercurialEclipse/dialogs/CommitDialog.java#640
>>>
>>>
>>>>
>>>>> IIRC, we considered having an option to specify the parents, but we
>>>>> decided to go for the simple --bypass version first, as it was really
>>>>> a test-bed for the working dir-less patcher. Maybe a --bypass-parents
>>>>> taking a revset would be good enough.
>>>>
>>>> --bypass-parents would work well and doesn't look like a big change.
>>>> Would a corresponding patch be accepted?
>>>>
>>>> --
>>>> Best regards,
>>>> Marc Strapetz
>>>> =============
>>>> syntevo GmbH
>>>> http://www.syntevo.com
>>>> http://blog.syntevo.com
>>>>
>>>> _______________________________________________
>>>> Mercurial-devel mailing list
>>>> Mercurial-devel at selenic.com
>>>> http://selenic.com/mailman/listinfo/mercurial-devel
>>>>
>>>
>>>
>>>
>>
> 
> 
>