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

Kostia Balytskyi kobalyts at outlook.com
Tue Feb 7 06:02:11 EST 2017



On 06/02/2017 23:22, Sean Farley wrote:
> 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 understand that. I did not mean to say that this approach is perfect 
(and should not undergo a patch review), it more like "it's not just my 
crazy idea".
>
> I'll go through this series more in-depth now unless someone beats me to
> it.



More information about the Mercurial-devel mailing list