Difficulties with permanence of obsolete markers

Scott Bilas scobi at unity3d.com
Wed Jun 29 14:03:12 UTC 2016


On Wed, Jun 29, 2016 at 10:25 AM, Lars Westerhoff <lars.westerhoff at newtec.eu
> wrote:

> > I assume what we're running into is an explicit design decision to avoid
> > instability. The end result is that it's making our people very
> > tentative about doing hist editing and fully trusting evolve.
> > [...]
>
> I also assume that it is by design as it completely defies the purpose
> of obsolete markers if they are deleted if the affected changesets may
> have been shared.
>

Well, I don't see it as too much different from stripping commits that may
have been shared. In fact, that's one of the reasons I use evolve - I'd
strip from one clone only to have it accidentally show up again because I
didn't realize I had indirectly pulled it into another. It's just that
evolve goes a little too far in its guarantee.

When I work in my local repo, I can do anything I like and have confidence
that I can undo it without much effort. Commits I don't want can be
stripped. Phases can be forced. Stripped commits can be re-applied from
auto-backup. Mercurial works hard to avoid loss of work, and it's one of
the things I absolutely love about it.

But when it comes to, say, pruning a commit by accident, I have to choose
one of:

  * Re-clone (the nuclear option, but easy, but omg loss of work potential)
  * Nuke obsolete markers and refresh from a similar clone (if I've got
one, also has loss of work potential)
  * hg touch to bring it back (safe, but has major implications on push)
  * hg debugobsolete (error prone, much manual labor)

At the end, though, what I was mainly asking for is hg debugobsolete, which
I didn't know about, and thank you for letting me know. :) I can wrap that
up with another extension to make it nicer and safer to use as 'unprune'.

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-evolve-testers/attachments/20160629/5f5416e3/attachment-0002.html>


More information about the Evolve-testers mailing list