[PATCH] shelve: adds option keepbranch to restore branch after unshelve (issue5048)

Piotr Listkiewicz piotr.listkiewicz at gmail.com
Wed Feb 10 16:29:21 EST 2016


>
> What do you mean with branchname of the shelved commit. In my
> implementation, shelved-commit are not really a thing. They are just and
> implementatin details.


Totally right, i didnt know how to describe it, so it turned out to be messy

The question here seems to be "What should shelve do with uncommited branch
> name change"
> - I'm pretty sure we don't want unshelve to drop uncommited branch change
> in the general case
> - If there is an uncommited branch change at shelve time should we:
>   - Include it in the shelve data (and restore it on unshelve)
>   - Ignore it a shelve time (but not loosing it).
> I all case I think we can define a sensible behavior here and implement
> it. I currently see no need for a new flag.


 I implemented this as new flag because in bugtracker discussion leaded me
to think that this is reasonable behaviour not breaking backward
compability. Of course after defining behaviour i will be happy to try to
implement it in next patch.



2016-02-10 22:01 GMT+01:00 Pierre-Yves David <pierre-yves.david at ens-lyon.org
>:

>
>
> On 02/10/2016 01:33 AM, liscju wrote:
>
>> # HG changeset patch
>> # User liscju <piotr.listkiewicz at gmail.com>
>> # Date 1455067407 -3600
>> #      Wed Feb 10 02:23:27 2016 +0100
>> # Node ID 35eeb40ad5c59ce6fe9384ca1b6098647692057b
>> # Parent  a036e1ae1fbe88ab99cb861ebfc2e4da7a3912ca
>> shelve: adds option keepbranch to restore branch after unshelve
>> (issue5048)
>>
>> Before this patch unshelve has no option to preserve branch name
>> of shelved commit. This patch adds --keepbranch option to
>> restore branch name.
>>
>
> What do you mean with branchname of the shelved commit. In my
> implementation, shelved-commit are not really a thing. They are just and
> implementatin details.
>
> The question here seems to be "What should shelve do with uncommited
> branch name change"
>
> - I'm pretty sure we don't want unshelve to drop uncommited branch change
> in the general case
>
> - If there is an uncommited branch change at shelve time should we:
>   - Include it in the shelve data (and restore it on unshelve)
>   - Ignore it a shelve time (but not loosing it).
>
> I all case I think we can define a sensible behavior here and implement
> it. I currently see no need for a new flag.
>
>
> --
> Pierre-Yves David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160210/1eb6a182/attachment.html>


More information about the Mercurial-devel mailing list