[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.

[acjohnson55]

I guess maybe the counterargument is that perhaps this should happen invisibly and automatically.

[skriticos2]

You just ran a script that scattered production / sensitive information in your source files. You definitely don't want to get that into history and get the last head state back.. Yes, you can delete the working tree and check out head again, but than again, git reset --hard pretty much does that and it's welcome at times.

[Skinney]

Well, there is to my knowledge no other vcs that does this. Mercurial will hapily blow your changes away if you do a hg update -C. If you want your changes to stick around, you do a git stash first.

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

[jlgreco]

https://news.ycombinator.com/item?id=6752077

Understand that I am very pro-git. I'm just trying to be precise here.

[jheriko]

i was too strong with 'unrecoverable'

'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.

[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”.