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

[Augie Fackler]

On Mon, Feb 06, 2017 at 03:22:56PM -0800, 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 is probably a good point. As long as use of shelve this way is
tied to obsolete markers already being otherwise-enabled, it's
probably fine?

I do like the idea that came up in IRC of having multiple ways of
hiding a change though. That might be a real winner (in particular
here because shelves aren't ever going to be exhcanged, so it's silly
to pay exchange/discovery overhead for something we know we'll never
share.)

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

Thanks, appreciated.

> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel