3 ms·

git reset is basically git unfuck. It comes in handy when you mess up and want to get back to the working state. So yeah, it nuked your file, as if wasn't par

• kazinator 4y ago
  > is basically git unfuck Yes, when the odd time it's not being git fuck. That's the point. "git reset --hard" is a command I reach for umpteen times daily. Its use cases cannot be replaced by "git reset". It isn't just some rarely-used footgun used by Git gurus, who reason very carefully about all of its corner cases and implications in that once-in-a-blue-moon situation. It's a daily driver. "git reset --hard" could use its own safety mechanisms. When "git reset --hard" is discarding staged adds, there would be zero downside in simply not removing the goddamned files. "git reset --harder" could do that, for people who like to lose files in corner cases. When "git reset --hard" is not discarding staged adds, but, say, navigating from a commit where a file exists to one where it doesn't, then in that case it's perfectly fine to remove. Another safeguard needed in "git reset --hard" is that when you reset to a particular commit which has a file, it will overwrite a local file which is in the way. That could use a safeguard. "git reset --hard" could refuse, but "git reset --harder" would do it. When I say, "go to this commit and make the working tree look like it", I don't mean that I want to ignore conflicts (that I don't even know about) between that commit and local files.