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

[Pierre-Yves David]

On 02/11/2016 04:23 PM, FUJIWARA Katsunori wrote:
>
> At Wed, 10 Feb 2016 21:01:24 +0000,
> Pierre-Yves David wrote:
>
>> 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.
>
> Expected behavior of "hg shelve":
>
>      ------- ---------- ---------
>      before  shelved    after
>      ------- ---------- ---------
>       P/P      P         P/P
>       P/A      A         P/A(*1)
>      ------- ---------- ---------
>
> "before" and "after" columns describe branch name of "parent of the
> working directory"/"the working directory". Therefore:
>
>    - "P/P" means that branch name isn't changed
>    - "P/A" means that there is uncommitted branch name change (P => A)
>
> "shelved" column means what branch name should be stored into bundle
> file.
>
> In fact, current "hg shelve" implementation doesn't preserve
> uncommitted branch name change in case (*1) above as expected :-<
> This should be fixed, shouldn't it ?

I'm not sure. I'm tempted to says we should either:

- Shelve the branch-change, therefor remove it from the working copy,
- Ignore the branch-change therefore preserve it in the working copy,

I'm not sure that doing both "saving the data" and "preserving it in the 
working copy" make sense. Because shelve is not doing both for anything 
else.

In all case, adding some warning/message about what is happening should 
be a win.

> On the other hand, expected behavior of "hg unshelve":
>
>      ------- ---------- ---------
>      before  unshelved  after
>      ------- ---------- ---------
>       P/P      *         P/P
>       P/A      *         P/A(*2)
>      ------- ---------- ---------
>
> "unshelved" column means what branch name is held in the bundle file
> to be unshelved.
>
> As same as "hg shelve", "hg unshelve" loses uncommitted branch name
> change in the case (*2) above. But here, let's assume that it is
> already fixed :-)
>
> I understand that "--keepbranch" focuses on users, who want to restore
> branch name saved at "hg shelve". Therefore:
>
>      ------- ---------- ---------
>      before  unshelved  after
>      ------- ---------- ---------
>       P/P      *         P/P      default case
>                B         P/B      usecase of --keepbranch
>
>       P/A      *         P/A      default case
>                B         P/B      usecase of --keepbranch
>      ------- ---------- ---------
>
> I commented about "adding --keepbranch" on bugzilla just for
> similarity to "hg rebase".
>
>      https://bz.mercurial-scm.org/show_bug.cgi?id=5048#c7
>
> But "--restore-branch" or so might be better for the purpose of it.

I really don't think we should add an extra flag for that. I don't think 
that looking at the branch of the "shelve-commit" only is good enough. 
In the case of shelve "shelving" branch-change we are recording a very 
specific information: working copy had a different branch. We have to 
store this specific information and restore it only in this case. In 
other word, I do not care what branch we were on when a shelve was made, 
I want to have special branch behavior only if the working copy was 
preparing a branch change. We can store/detect that information by 
checking if the "shelve-commit" have a branch different from its parent. 
In that case, and only in that case we would restore the new branch into 
the working copy.

Of course, if we decide that shelve is ignoring branch change (with a 
warning), unshelve does not need to care about anything but preserving 
the working copy branch.

Cheers,

-- 
Pierre-Yves David