On 06/02/2017 23:22, Sean Farley wrote: > Kostia Balytskyi <kobal...@outlook.com> writes: > >> On 06/02/2017 19:41, Sean Farley wrote: >> >>> Kostia Balytskyi <kobal...@outlook.com> writes: >>> >>>> On 03/02/2017 23:17, Sean Farley wrote: >>>> >>>>> Kostia Balytskyi <ikos...@fb.com> writes: >>>>> >>>>>> # HG changeset patch >>>>>> # User Kostia Balytskyi <ikos...@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.
_______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel