[PATCH 2 of 2] rollback: avoid unsafe rollback when not at tip (issue2998)

Laurens Holst laurens.nospam at grauw.nl
Fri Sep 30 06:32:16 CDT 2011

Op 30-09-11 04:55, Greg Ward schreef:
> # HG changeset patch
> # User Greg Ward<greg at gerg.ca>
> # Date 1317350673 14400
> # Node ID c10af212a55cbfa84b5d5182ee41028c4baa33c6
> # Parent  f295542f482d4b567fa6229b93c1854aca78792c
> rollback: avoid unsafe rollback when not at tip (issue2998)
> You can get into trouble if you commit, update back to an older
> changeset, and then rollback. The update removes your valuable changes
> from the working dir, then rollback removes them history. Oops: you've
> just irretrievably lost data running nothing but core Mercurial
> commands.  (Or, more subtly, rollback from a shared clone that was
> already at an older changeset -- no update required, just rollback
> from the wrong directory.)
> The fix assumes that rollbacks can be considered "safe" or "unsafe". A
> safe rollback is one that aborts a transaction whose data already
> exists somewhere else: pull, unbundle, or push. Don't be so picky
> about rolling back those transactions, since the repo or bundle from
> which they came presumably still exists. Every other rollback, most
> typically of a commit transaction, is considered unsafe. Finally, you
> can get back the existing dangerous behaviour with --force.

Why is rolling back a commit you just did unsafe? As long as you haven’t 
updated to a different revision, all your code will still remain in the 
working copy, your dirstate is also kept intact, and even the commit 
message is still available in tools like TortoiseHg or the command line 
history. So I don’t think any information is lost there, and this is for 
me the no. 1 case where I use rollback, it would suck if I had to start 
habitually adding a --force flag. Then there would be no protection 
anymore from the cases where there is actual data loss.


More information about the Mercurial-devel mailing list