Search code examples
gitrestorerecovery

Recovering files lost by git checkout (not staged/commited)

I know this was a stupid mistake, but hear me out.

I have a git repo (which has a remote on GitHub) and I wanted to create a new branch. I wouldn't say that I am very new to git, I have used it for quite a long time and like to think that I can do some decent repo work.

Now, this repo is mostly full of binary data, and that is because the repo doesn't have code, rather it has proprietary data files in binary which my software uses.

Back to the problem, I decided to create a new branch for my partner, who works with different data files. My working tree was not clean and there were about 2 or 3 modified files and 1 new file. I ran the following:

git branch kicad
git checkout kicad

(no error is shown about dirty working tree/uncommitted changes)

rm ./my_data_files
md partners_data_files

git add .
git commit

This deleted my project and data files and prepared for my partner's. When I switched back to the main branch I was pleasantly shot in the head by the loss of my work. My data files were still there, but the changes that I made and did not stage/commit were gone.

I tried to recover this for about 2 hours now, unsuccessfully.

Here are the outputs for some commands:

  1. git reflog
0fad3c8 ... checkout: moving from kicad to main
3b0a8dc ... checkout: moving from kicad to kicad
3b0a8dc ... checkout: moving from main to kicad
0fad3c8 ... reset: moving to HEAD

(This is when I realized changes were gone)

0fad3c8 ... checkout: moving from kicad to main
3b0a8dc ... commit: Initial Kicad Commit

0fad3c8 ... checkout: moving from main to kicad
0fad3c8 ... commit: Connected VCC, might have to redo due to uC stuff
  1. git fsck --lost-found
Checking object directories: 100% (256/256), done.
Checking objects: 100% (1266/1266), done.
dangling blob acd050aef0bd6151b46f99ea038af062110622ad
dangling blob dae060387c5998e4c2461fbaf003558222eb30d0
dangling tree 1f21c30039821372359108c6bc747a7510f93ce7
dangling blob c53216ba759028d68c64ca80bb1cc23a3aa025a9
dangling commit d8b2cf1f8c088f9fcc6990bd788bbc18615ebe41
dangling blob e642369390cb27753f17fee430a60db08719115a
dangling blob 7004c58d393d1e54c6080a8bf4eae9a56f25c160
dangling blob 8914c8d1aa0d9857fc9dfd7680db9590916827b1
dangling blob aa9433c2a651ad8c9878274007f39e61562570d8
dangling blob 5fa66c17c63b384a8120dee4dbadb726427e372e
dangling blob 22b71a4553fe6af87528aafaeb50133e21ca9938
dangling blob 3197630158eb88f93d2626a3cca8c1dab52d50b8
dangling blob 0308d60f2b21f83d941fdff735888549d19f17b1
dangling blob 7f68dac2ec15393bea041d87541d1fbb360bc065
dangling tree 8588ef3d5242870e9aedf782674122ab20b8f28f
dangling commit 35d9c0eb3b49b808ffa2178a3f098fe7a4b44d91
dangling commit 38ed38b357bb113d6bd43d99b391711933db123b
dangling commit 371d767b784a7119b3523de88aeee85748f83230
dangling blob 539dccc2799619ccd7bd588b0615415f25f62bed
dangling blob c5fd0dc4261c1481f3a3991c2311440643df9aac
dangling blob 087ed8e94498048c6702fd098e0d948593d9d93b
dangling blob 2b5e415606b875839c782cb226762273b023793d
dangling blob c14e5265de71f27b74cc06fb461886753b495021
dangling blob db4f32caf30cdf922918315954ffa3d1d0e775d8

I tried resetting, reverting, checking out, but nothing worked.

The repo is here. I read some answers which stated that it was not possible, but I am not sure about this one. Any responses will be welcomed and I will be happy to provide details.

Edit 1: I am not trying to recover those deleted files. What I am trying to recover are the changes that were lost when I checked out of the main branch into the other branch (kicad), in which I deleted the files.

Solution

  • Edit 2:

    Just to review - the steps laid out in the question were

    git branch kicad
git checkout kicad

(no error is shown about dirty working tree/uncommitted changes)

rm ./my_data_files
md partners_data_files

git add .
git commit

    When told by multiple people that the rm deleted the data (rather than any git operation), OP indicated that the rm'd files were not the ones containing the changes in question.

    Now based on their most recent comments, it appears that is not, in fact, true. Frankly I would delete my answer if I were able to, because I have very little patience for people changing their story and wasting my time when I'm volunteering help.

    ====

    Edit: I've been reading your comments about how the rm'd files aren't the ones you're trying to recover. It took me a few tries to understand what happened, because you keep implying something that is not true: that changes are lost when you change branches.

    After you did the git checkout, the changes were still there as unstaged chagnes.

    When you said git add . you staged them.

    When you committed your partner's branch, you committed those changes with them.

    And when you switched back to your own branch, git said "oh, well, the changes you committed to that other branch are not relevant to this branch we're switching to" - because that's what branches are.

    So you actually have two related problems:

    1. You committed changes to your partner's branch that probably don't belong there

    2. You need those changes in your worktree

    So you should be able to find your branches by diff'ing your brnach with your partners. From there you can checkout individual files from his branch to restore those changes to your worktree.

    git checkout other_branch -- path/to/file

    Once you've restored your working state, you'll also need to clean up the other branch. A similar procedure (checking out files from your previous committed state into a worktree on that branch) may suffice.

    I'm leaving my original answer as well, because going forward the advice at the end still applies.

    ====

    In no way does git know about changes that were never staged. Commands that report on such changes are getting their information directly from the working files, so if those are gone, there's nothing left for git to tell you. If you have backups, you can restore from those.

    You mention that git didn't give any warning. Since the command you were executing (switching to another branch that was pointed at the same commit as your current HEAD) didn't affect the working tree, git had no reason to think you were doing anything dangerous. It wasn't until the subsequent rm - a non-git command - that any data was lost.

    My advice going forward would be:

    1. If you're going to do something that needs your working state out of the way, use git stash (maybe even git stash -u) to get to a clean worktree state while being able to restore your working state. https://git-scm.com/docs/git-stash

    2. For this operation, you could've avoided involving your worktree at all, either by creating a new worktree (https://git-scm.com/docs/git-worktree) or by simply cloning again. This would give you a separate working area in which to create the new branch.

    3. In any event, your worktree is the storage area most vulnerable to data loss since changes there haven't yet been added to git's database. So if you're going to do anything destructive to the worktree (like an rm command), you could use git status to double-check that you know what you might lose.