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.