Git Checkout Behavior

Question

I have an issue with using Git through the terminal. I was ready to add my changes to the branch and commit them. And I messed it up and lost all my changes before I could get them back. Here's the command I ran.

git checkout name
Update 6 paths from the index (This is where I lost all my changes.)

git checkout -b name
git status (This is when I found all my changes were gone.)

I forgot to add the -b in the checkout but I don't think missing the -b should have done anything. Then I tried

git reflog
1234e (HEAD -> name, origin/master, origin/HEAD, master) HEAD@{0}: checkout: moving from master to name
1234e (HEAD -> name, origin/master, origin/HEAD, master) HEAD@{1}: checkout: moving from master to name
1234e (HEAD -> name, origin/master, origin/HEAD, master) HEAD@{2}: checkout: moving from master to name
1234e (HEAD -> name, origin/master, origin/HEAD, master) HEAD@{3}: checkout: moving from master to name

I then tried to checkout via the 1234e and still no luck on getting my changes back and even went further back to the an earlier one and look luck on that one either. So far the internet has run up dry for this problem. I hope I still have my changes, I really don't want to do the work again as it's a few hours worth of work. Anyone have an idea to get my changes back?

Thank you!

question from:https://stackoverflow.com/questions/65943989/git-checkout-behavior

Answer 1

Unfortunately, the git checkout command has two completely different behaviors it can invoke:

• git checkout paths: this destroys any uncommitted work, irrecoverably,¹ without asking if that's OK;
• git checkout branch: this carefully checks out the given branch, refusing to do anything at all if this would destroy any uncommitted work (unless you provide a --force flag or similar).

This is not beginner-friendly. Heck, it's not even experienced-Git-user-friendly. The Git folks finally took care of this problem, after more than a decade of it being a problem, in Git 2.23: they split the git checkout command into two different commands.

One command—git switch—implements the safer behaviors. Unless you use specific options like --force, it will never destroy uncommitted work. The other, git restore, implements the "unsafe" behaviors: it will overwrite uncommitted files without question, since it assumes you have declared that you know what you're doing by running git restore in the first place.

If you have Git 2.23 or later, it's probably wise to retrain your fingers to type git switch instead of git checkout. (I am still in this process myself.) In Git 2.23, the particularly insidious case—the one that occurs when you give it a name that's both a branch and file or directory name—git checkout stops being quite so evil, but it's still wise to retrain your fingers.

I forgot to add the -b in the checkout but I don't think missing the -b should have done anything.

The message Updated 6 paths from the index indicates that it did (and that the recovery via the git add trick I mention in the footnote does not apply here).

---

¹The "irrecoverable" part here is:

• specific to Git: if you have something like Time Machine on macOS working, you may be able to get your work back that way, or if your editor makes backups, you might be able to get at those (I have no idea whether your editor does that); and
• not 100% accurate.

In particular, if you ran git add, Git did look at your uncommitted work and prepared it for being committed. The subsequent git checkout may have destroyed the preparations, but the preparation work may have left traces that allow recovering some or all of these files.