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

[Sean Farley]

Kostia Balytskyi <kobalyts at outlook.com> writes:

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

Ah, yep, I forgot my version was performing a strip. We'd need the
markers to not be stripped in this case.

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

Discovery and exchange of markers is absurdly slow. *Absurdly*. I'm not
saying we should block features due to technical limitations (and a
promise that discovery will be "fixed" ... one day ... maybe next year).
I'm just saying we should think really hard about using them like this.

> This direction of doing shelve was discussed on the 
> last sprint and people who participated
> did not seem much against it :)

Keep in mind not everyone gets to participate in the sprint discussions.
I think sprint discussions are fine for agreeing that something should
be worked on but in no way should override a patch review.

I'll go through this series more in-depth now unless someone beats me to
it.