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. > 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. > [...] _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
