Interestingly, things like this won't happen with the git repository model because it is persistent. New commits doesn't overwrite the old commits in the repo in any way, so you can always get back to a known state.
The only destructive packing operation takes great care in making sure it has stable storage before deleting stuff.
No, it doesn't save you from a dead disk, but at least you can at any time ask for the consistency of the repository.
And finally, it is good to see Zed learning from the experience :)
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.
Or `git checkout file.py` for that sake. git should really create a file.py.orig like hg does or provide some alternate way to undo an incorrect checkout/reset.
git reset --hard will only orphan commits, they're still there. git reflog will get you to them fast and I'm sure there's many other more exotic ways to find them. Admittedly garbage collection will remove them at some point but that's generally a lot further away than 'oops'.
You can't rewrite history in git either. You can however make new commits that are different from the old commits somehow. A branch in git is basically just a pointer to a set of immutable commits. http://hackerne.ws/item?id=2524993
Branches and tags are just "Stick-it-notes" you attach to the DAG. They can be removed around at whim, but they only serve to mark a point in the DAG for your convenience. The GC process will kill parts of the DAG with no such branch/tag, but it only happens after some days by default.
Were git able to rewrite history, it couldn't use SHA1 checksums as names for the content. Note that a rebase alters the SHA1 stack you have, so it is regarded as something different. But you can't do that easily with published stuff as it would render further work impossible.
Fast forward is the recognition that a stick-it-note can be moved linearly ahead.
You won't be rewriting history, you will be writing new history and then forget about the old. But it is still there should accidents happen.
