6 ms·
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
by jlgreco 13y ago
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 13y agoOk, 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 13y agoI guess maybe the counterargument is that perhaps this should happen invisibly and automatically.
- skriticos2 13y agoYou 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 13y agoWell, 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 13y agoThis 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 13y agohttps://news.ycombinator.com/item?id=6752077 https://news.ycombinator.com/item?id=6752077 Understand that I am very pro-git. I'm just trying to be precise here.
- jheriko 13y agoi 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.
- tripa 13y agoI'd be surprised if mercurial didn't have a similar “feature”.
- ryanbrunner 13y agogit 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.