Hidden Commits in 4.3

Jun Wu quark at fb.com
Tue Apr 11 22:51:35 EDT 2017


Excerpts from Jun Wu's message of 2017-04-11 14:11:55 -0700:
> Excerpts from Pierre-Yves David's message of 2017-04-11 22:29:15 +0200:
> > The issue you face here is related to known limitation of `hg strip`. 
> > When it removes the changesets, strip should also remove the 
> > obsolescence markers leading to them.
> > 
> > That will be fixed soon. Having strip able to remove obsmarker has been 
> > close to the top of the evolve roadmap[1] for some times and it is on 
> > the funded path.
> 
> strip is just one case. precursor (i.e. len(successors) > 0) hiding is also
> un-hide-able. And I think that's also a problem. So fixing strip alone does
> not solve all of them.
> 
> > [...]
> > I'm going to repeat myself here: hiding is an important feature of 
> > changeset-evolution and part of the global state it allows people to 
> > propagate[2].
> 
> I think the hiding itself does not conflict with evolve directly. The fact
> that the new "unhide" command could introduce cycles could conflict with the
> current evolve design. That is a problem of evolve itself to solve, not a
> problem of core hg hidden store.

To add clarification, I think the obsmarker cycle problem (which has been
there for many years) is solvable. As I understand it, there are 3 solutions:

  a) The "auto rebase" proposal [1]
  b) The "node versions" approach I had sent before
  c) Build an obsmarker DAG and introduce new concepts to do marker merges
     and conflict resolution (with some unknown UI)

Currently I prefer "a" because it's much simpler, just works, and I think it
has better behavior in some cases (ex. a stack: A - B - C; amend B -> B',
strip B', then B gets revived automatically. strip B' means the amended
revision B' is a failure, it does not mean both B and B').

[1]: https://goo.gl/wuP2Vl

> > Mixing it with local only elements will not work. They are tons of 
> > simple case where we won't be able to determine a simple and consistent 
> > behavior for it. Even the local case can quickly raise shortcoming to 
> > the above proposal:
> 
> Could you give a practical example (i.e. hg commands) that things do not
> work? That will be more helpful than repeating the abstract concepts.
> 
> As said above, I'm fully aware of that evolve cannot handle cycles. So
> please avoid giving examples that create obsmarker cycles. They're known
> already.
> 
> > [...]


More information about the Mercurial-devel mailing list