strip does not fail on public changesets

[Matt Mackall]

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.

-- 
Mathematics is the supreme nostalgia of our time.