3 ms·
You can git reset --hard and still get your work back without much trouble. Resets just move the branch pointer back, after all.
by stu2b50 4y ago
You can git reset --hard and still get your work back without much trouble. Resets just move the branch pointer back, after all.
- cryptonector 4y agoHard resets throw away extant changes in the workspace that are not in the index or committed. You can't find those changes in the reflog or stash.
- remram 4y agoIt also throws away changes from both the working copy and the staging area.
- cryptonector 4y agoOnly if --hard is given.
- remram 4y agoWhich is what we're talking about.
- cryptonector 4y agoRight, so stop typing that at all. Instead use `git checkout -f` to throw away extant changes. The `-f`/`--force` option is a lot clearer in intent than `--hard`.
- remram 4y agoThe GP was talking about "moving the branch pointer", which checkout does not do. I am encouraging you (for the second time) to read the thread you are replying into... git checkout can also nuke changes from both working copy and staging area. `git checkout <path>` will nuke working copy (and auto-completion is likely to give you a path when you were looking for a branch), `git checkout <ref> <path>` will nuke both. No --force required in either case, so let's not pretend that you can't lose changes without a scary-looking flag like --force or --hard.
- cryptonector 4y ago> The GP was talking about "moving the branch pointer", Not explicitly. `git checkout ref path` implies `--force`, since you're being specific. I would prefer if Git could keep a GCed pile of saved workspace changes every time you force checkout/reset. But for the love of all that is good, stop using `git checkout`/`git reset` in the few ways they hurt.