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