[PATCH 08 of 10 shelve-ext v3] shelve: add obs-based unshelve functionality

[Kostia Balytskyi]

On 06/02/2017 19:41, Sean Farley wrote:

> Kostia Balytskyi <kobalyts at outlook.com> writes:
>
>> On 03/02/2017 23:17, Sean Farley wrote:
>>
>>> Kostia Balytskyi <ikostia at fb.com> writes:
>>>
>>>> # HG changeset patch
>>>> # User Kostia Balytskyi <ikostia at fb.com>
>>>> # Date 1484835394 28800
>>>> #      Thu Jan 19 06:16:34 2017 -0800
>>>> # Node ID 94a237a046059ef246aacb2c3ad809c9f0bdbe70
>>>> # Parent  abdf9565fdce15604ea4abf013cb7c98a11f70ca
>>>> shelve: add obs-based unshelve functionality
>>>>
>>>> Obsolescense-based unshelve works as follows:
>>>> 1. Instead of stripping temporary nodes, markers are created to
>>>> obsolete them.
>>>> 2. Restoring commit is just finding it in an unfiltered repo.
>>>> 3. '--keep' is only passed to rebase on traditional unshelves
>>>> (and thus traditional rebases), becuase we want markers to be
>>>> created fro obsolete-based rebases.
>>>> 4. 'hg unshelve' uses unfiltered repo to perform rebases
>>>> because we want rebase to be able to create markers between original
>>>> and new commits. 'rebaseskipobsolete' is disabled to make rebase not
>>>> skip the commit altogether.
>>> Before this gets into core, can we not implement stripping obs markers?
>>> This seems like a good use-case for such functionality.
>> I am not sure I understand why stripping obs-markers is a pre-requisite
>> here. Can you explain?
> Perhaps I'm the only one worried about adding all these markers. To me,
> it would make more sense to delete these markers since we're never going
> to push these shelved changesets.
Deleting markers would mean changesets are no longer hidden, no? And if 
you want to strip changesets as well, then I don't see the point in 
having markers at all.
> Also, this sounds like we're overloading the concept of markers. In the
> past, I have wanted a concept of "markers that hide changesets" but to
> group them into different namespaces. For example, remote branches not
> checked out locally could be hidden into one such group, shelved changes
> into another group, etc.
>
> Though, I do realize I might be derailing this topic by trying to
> generalize this.
I don't think I understand your opinion about markers, but it probably 
applies more broadly than
just obs-shelve. This direction of doing shelve was discussed on the 
last sprint and people who participated
did not seem much against it :)