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