[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.
~Laurens
More information about the Mercurial-devel
mailing list