0

I accidentally did

git reset --hard origin

earlier, and followed the instructions in How to undo 'git reset'? and did a git reset HEAD@{1} (note that git reset --hard origin was the last command I executed prior to executing this command).

This revived all my unstaged/uncommitted changes, but it seems to have also revived my changes from earlier commits. I see the files modified in my previous commits in my "Changes not staged for commit" currently.

I am wondering why this happened?

user5965026
  • 465
  • 5
  • 16
  • The `--hard` reset told Git to replace all your working tree files, so you have the `origin/master` or `origin/main` version of those files now. The subsequent `git reset HEAD@{1}`, without `--hard`, told Git *not* to replace your working tree files. So they're still unchanged from the first reset. But your *current commit* and the *proposed next commit* (in Git's index / staging-area) are correct, it's just your *working* files that are changed-back. Those are the "not staged for commit" changes. – torek Mar 03 '22 at 00:06
  • Now that `HEAD` and the current branch name select the most recent commit, you can run `git reset --hard HEAD` to tell Git: (1) move the current branch zero steps away from where it is, so that it doesn't move at all; (2) reset your index/staging-area to what it has in it, so that it doesn't change at all; (3) remove and replace all my working-tree files with those in the current commit. – torek Mar 03 '22 at 00:07
  • Had you used `git reset --hard HEAD@{1}` earlier, you would have had Git replace the working-tree files at that time. But you didn't, so now you need to do that. Note that if you had uncommitted work, you lost it on the first `git reset --hard`, so this second "lose my uncommitted work" doesn't do any *further* damage. It's still something to remember for the future though: `--hard` means *erase work not saved in Git, if there is any*. – torek Mar 03 '22 at 00:09

0 Answers0