Aryeh Gregor wrote:
My experience with Mercurial is that if you type the
wrong commands,
it likes to destroy data. For instance, when doing an hg up with
conflicts once, it opened up some kind of three-way diff in vim that I
had no idea how to use, and so I exited. This resulted in my working
copy (or parts of it) being lost, since apparently it defaulted to
assuming that I was okay with whatever default merging it had done, so
it threw out the rest. I also once lost commits under similar
circumstances when doing hg rebase. I'm pretty sure you can configure
it to be safer, but it's one of the major reasons I dislike Mercurial.
(I was able to recover my lost data from filesystem backups.)
git, on the other hand, never destroys committed data...
Mercurial doesn't destroy committed data, either. You just ended up in a
situation that you didn't know how to exit. Very much like being trapped
into vi and, not knowing the keys to exit, killing it (yes, I have done
that in the past).
A hg merge is not undone by the revert command. You need to do hg update
--clean
Another -more generic- explanation on how you could have reset a borked
working copy, is that you could have cloned the previous copy, as that
would always set you back to the latest commited revision. It seems a
failure cloning repos for doing alternate work, but DCVS seem fond of
suggesting that you should have clones for separate working (yes, they
use hardlinks, but it still seems too much). Something like git stash
seems the way to go.