Desired use case for obsmarkers / visibility

[Pulkit Goyal]

I agree that the exchange of obsmarkers don't have a very good UI. Not
only the prune markers, in case of divergence we don't have a good UI
yet. I have an idea as follows:

1) Let's keep push behavior as what it is today.

2) For each pull, let's write a state file (or some obsfile) which
will store the information of obsmarkers pulled which changed the
existing state.
For example: If Alice pulls, we will store information related to
obsmarkers which are created on Alice changesets by someone else. We
can make this logic a bit smart and also include obsmarkers which
causes divergence.

3) Introduce a new command or plug the functionality into pull where
user can see what are the changes caused by pull using the state file
stored in part 2 and can confirm which changes to keep. In case a user
does not want to revive a changeset which was pruned by someone else,
the command will do that. In case of divergence, user can pick which
one to choose and the command can create a obsmarker obsoleting the
one user didn't want in favor on one he wants. I am already thinking
how good a curses UI will be for this.

4) By storing information as mentioned in 2nd point, we can also know
which pruned changesets we need to keep visible for sometime until
either the user confirms the prune or revive that.

This will cause problems in cases when a user works with multiple
accounts which I think can be solved by having a concept of user alias
or user group kind of thing.

On Thu, Nov 16, 2017 at 1:15 AM, Jun Wu <quark at fb.com> wrote:
> 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.
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel