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. > 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 :) _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel