strip does not fail on public changesets

Angel Ezquerra angel.ezquerra at gmail.com
Sun Apr 1 15:36:39 CDT 2012


On Mar 31, 2012 6:16 PM, "Matt Mackall" <mpm at selenic.com> wrote:
>
> On Sat, 2012-03-31 at 01:23 +0200, Angel Ezquerra wrote:
> > Today I was _very_ surprised when I discovered that you can strip
> > public changesets.
> > It was a bit embarrassing because I was just touting how safe
> > mercurial is to a new user. I was telling him how mercurial protects
> > you from shooting yourself on the foot by modifying shared revisions
> > when I tried to strip a public changeset expecting it to fail. Instead
> > mercurial happily stripped the changeset!
> >
> > On hindsight I guess that one could argue that stripping a public
> > changeset should be fine, since you should be able to get it back by
> > pulling again. Nevertheless it was still quit surprising and
> > unexpected to me that you can do it.
> >
> > Is this the proper behavior? Shouldn't mercurial require that the
> > changeset is made draft before being able to strip it?
>
> Pierre-Yves and I discussed it before 2.1 and I didn't think that this
> broke the rules. Phases prevent modifying shared data, but a truncation
> is no different from other valid, "safe" operations like clone -r or
> simply not having pulled in the first place.
>
> Further, the goal of phases is not to prevent data loss, it's to prevent
> data duplication! If I strip a draft changeset, that's definitely loss
> (ok, ignoring the backup), because I've deleted the only copy of
> something in the world. But if I strip something I've pulled from a
> public repo, well, it's still out in the world. And if I strip the only
> copy of a public changeset.. was it really public? Instead phases try to
> prevent me from rebasing or otherwise modifying shared changesets and
> thus making duplicate parallel history.
>

Thanks for giving me some context on why it works this way. I agree that it
is the right behavior as well.

Nevertheless, the fact that I expected it to work differently in the first
place may indicate that others may be confused as well...

Angel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120401/f5be5c32/attachment.html>


More information about the Mercurial-devel mailing list