rollback deprecation

[Matt Mackall]

On Wed, 2013-07-17 at 23:25 +0200, Angel Ezquerra wrote:
> 
> On Jul 17, 2013 9:58 PM, "Matt Mackall" <mpm at selenic.com> wrote:
> >
> > On Wed, 2013-07-17 at 14:55 -0500, Kevin Bullock wrote:
> > > On 17 Jul 2013, at 10:56 AM, Antoine Pitrou wrote:
> > >
> > > > Kevin Bullock <kbullock+mercurial <at> ringworld.org> writes:
> > > >>>
> > > >>> Rollback is deprecated? What is the recommended way to undo a
> bogus
> > > >>> commit (especially a merge or graft)?
> > > >>> AFAICT, "strip" isn't part of the core command set.
> > > >>
> > > >> The same way we've always recommended: clone up to the parent
> of the
> > > > bad revision (and any other heads), then
> > > >> throw away the old clone.
> > > >
> > > > That's a terribly obnoxious solution compared to "hg rollback".
> > >
> > > It's a solution that works at the level of other user-facing
> commands,
> > > rather than digging dangerously into the internals of how revlogs
> > > work. It has -always- been our first recommended way of undoing a
> > > changeset you don't want.
> >
> > More precisely, it's in keeping with the append-only avoid-dataloss
> > approach of the rest of our core commands. In other words, the same
> > reason that strip is NOT in core.
> 
> I think that recloning to undo the last commit is clunky and user
> unfriendly, particularly if your working directory contains untracked
> files which are costly to regenerate.

I'm glad rollback works for you. You will NOT be affected by this
change.

We have lots of evidence that rollback does not work for beginners and
we have weighed the pros and cons about hiding it from them and that is
ALL that deprecating does.

-- 
Mathematics is the supreme nostalgia of our time.