RFE: hg import --bypass target should be customizable

[John Peberdy]

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
>>>
>>
>>
>>
>



-- 
John Peberdy