rollback deprecation

Angel Ezquerra ezquerra at
Wed Jul 17 16:25:31 CDT 2013

On Jul 17, 2013 9:58 PM, "Matt Mackall" <mpm at> 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>> 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.

For example, I work with projects that contain xilinx ip cores that take
more than an hour to generate from a newly cloned repo. Losing an hour to
undo a commit seems excessive. You could copy those untracked files to the
new repo, or something similar, but that would be error prone. Or you could
use strip but then isn't that bypassing mercurial's append only approach

It is true that amend is a better solution most of the time but it seems
that there are still some legitimate use cases of rollback...

Maybe rollback (or an equivalent evolution command) could turn the rolled
back revision hidden instead of removing it?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Mercurial-devel mailing list