From reading the mailing list thread, he didn't lose committed work. He lost uncommitted work. He told fossil to revert everything. I have no dog in this hunt, but I think its important to read the mailing list thread. There you can see people asking if he lost committed vs. non-committed changes.
fossil revert -- This is what destroyed my work.
They were *uncommitted changes*, so once I did this
they were gone. I didn't realize it'd nuke them
until it was too late.
Interesting. Because git doesn't protect you from that happening at all either :) It is a situation where shoot-yourself-in-foot is definitely possible.
hg does and I think git should do it as well. `hg revert file.py` creates a file.py.orig where file.py is being reverted. It does creates an extra file which you don't want but it's better in the cases where you accidentally reverted.
`hg purge` purges all files not tracked by mercurial and `hg rever --no-backup file.py` can be used when you don't want backup.
Considering its usefulness, I am happy to put up with untracked, original file it creates which I don't need most of the times; but boy is it a lifesaver when I do need it.
Wrong on both counts. Git's bizarre contrarian UI has screwed up many a repository. I can't tell you how many times some dude's weird "workflow" he decided was the best screwed everyone else on the project over.
In this case with fossil, the bug tied my hands so that the only way I could get the code back was to revert. It was a choice between trying to reverse engineer my original uncommitted work or revert and at least try to recover the repo. Since I don't work on more than one thing at once reverting was the best choice.
From this message, emphasis mine: http://www.mail-archive.com/fossil-users@lists.fossil-scm.or...