$ git init
Initialized empty Git repository in /home/john/tmp2/.git/
$ echo "foo" > foo
$ git add foo
$ git commit -m 'init'
[master (root-commit) 84fb5d1] init
...
$ echo "bar" >>foo
$ cat foo
foo
bar
$ git reset --hard HEAD
HEAD is now at 84fb5d1 init
$ git reflog
84fb5d1 HEAD@{0}: commit (initial): init
$ git status
# On branch master
nothing to commit (working directory clean)If you git reset --hard and you have a dirty working directory, you can absolutely blow work away. That's one of the main reasons to use git reset --hard, but I agree that it needs to be used with intention.
The easiest way to protect against it is to never use it if you have a dirty working directory, always commit first and then reset --hard after you've committed.
It just seems silly, sorry. And while I know little about hg I suspect it's not even true: hg will never delete a file it doesn't understand? What about the equivalent of git clean (which I use daily -- it's loss would be a minor hardship and definitely not an advantage for mercurial)?
Understand that I am very pro-git. I'm just trying to be precise here.
'unrecoverable in acceptable timescale with acceptable resource' would be accurate.
specifically i found it difficult to undo a merge and found that i was in a team where people had decided to use tools they didn't know enough about to have been using at all.
Which really, at the end of the day, is the real problem with git. It's not that it's inherently more dangerous, it's that the CLI is so inconsistent it can be hard to remember what you're doing, what's safe and unsafe, etc. Sometimes you need to pass "--force" for dangerous stuff, sometimes you capitalize the argument (like force deleting a branch). Sometimes "--hard" indicates that you should do the dangerous version of something. Sometimes there's not even a safety switch.