Desired use case for obsmarkers / visibility

Jun Wu quark at fb.com
Wed Nov 15 14:45:46 EST 2017


Excerpts from Augie Fackler's message of 2017-11-15 14:15:44 -0500:
> > On Nov 15, 2017, at 14:12, Jun Wu <quark at fb.com> wrote:
> > I think there are 2 kinds of "prune"s that might be treated differently:
> > 
> >  o C                       o C
> >  |                         |
> >  x B (B -> (), parent A)   | x B (B -> (), parent A)
> >  |                         |/
> >  o A                       o A
> > 
> > When pulling "C", I guess it's reasonable to pull the marker for the left
> > case.  The right case might want an option.
> 
> I think the left case is only viable because the change already doesn't
> disappear due to the anchoring of C. I think it's still plausible (likely
> even?) that the user will want to revise B and continue with it, or will
> otherwise prune the change locally if it ended up being a dead end.

My understanding was from a "branch" perspective, less about visibility:

By getting a marker in the left case, the user has a chance to solve
instability for "C" (the branch they care about) locally and sync a solution
to the server (otherwise the server might stay unresolved). In the right
case, they don't care about "B" branch right now (since B is not an ancestor
of C) so markers there do not matter.

But I understand it also makes sense sometimes to avoid the prune marker
even in this case.

I don't have a quick and "correct" solution right now. If we could make
more changes, I think a possible final situation that also simplifies a lot
of things is like:

  - Visibility is tracked at an level (probably even lower than phases),
    revised (like pinned_revs) at higher levels.
  - There are only 1:1 mapping markers. No prunes or splits.
  - A marker could have an optional "rebase hint" flag. Once set, it does
    not obsolete anything, but is only used for helping decide rebase
    destination. When splitting A to B and C, write a "rebase hint" marker
    from A to C and change visibility to hide A.

This actually disallows the above left case - rebase immediately is the only
way to get rid of commits in a stack.


More information about the Mercurial-devel mailing list