strip does not fail on public changesets

[Pierre-Yves David]

On Sun, Apr 01, 2012 at 10:36:39PM +0200, Angel Ezquerra wrote:
> 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...

In a future with a obsolete marker, the common way to get ride of a changeset
will not be strip anymore but a another command (currently named "kill" in my
experimental implementation). This command will do proper phase check while
strip should become a maintance command.


-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120404/32d210c5/attachment.pgp>