[tednaleid]

That's not correct, you can get back to any ref in the reflog, including those that you moved away from with git-reset --hard. Those commits are just dangling but are easy to get back to. I've got a presentation [1] that goes into how to use the reflog and how the various flags in reset work (among other things) that could explain more.

[1]: http://tednaleid.github.io/showoff-git-core-concepts/

[jlgreco]

My point is that git-reset --hard can remove data from the working tree filesystem that never hit the DAG in the first place:

  $ 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)

[tednaleid]

Ok, yes, I agree with that clarification (and I missed that you specified in your original comment "uncommitted work", my mistake).

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.

[ajross]

This is true, but seems specious. By this definition (development tools that can irrecoverably destroy data in the working directory) you should be flaming against vim too, not to mention rm or the dreaded "clean" target to make.

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)?

[ryanbrunner]

git reset --hard at least has the benefit of sounding like it's going to do something scary. "git checkout ." will also completely nuke your working directory without warning, and looks benign enough that you would never expect that problem.

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.

[tripa]

I'd be surprised if mercurial didn't have a similar “feature”.