Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

added new files during git interactive rebase, aborted rebase, new files missing

Tags:

git

I did a git rebase -i on a commit several nodes earlier. I added some new files I meant to add to that commit.

It looked like I was on the wrong node, so I immediately did a git rebase --abort. Those new files are now entirely gone. In the reflogs, it looks like a delete command was issued (deleted file mode 100644), but not even the file name is present.

This doesn't look good, but I figured I'd ask - is this recoverable?

like image 445
chaqke Avatar asked Oct 09 '22 17:10

chaqke


2 Answers

No, the changes were not "recoverable" in that they could be grabbed by a single command. Yes, the changes were found in a git fsck, along with 100+ other old changes that I had to sort through. Ick, but better than full loss.

Important things to note: - As soon as you do a "git add", that commit node is recorded - things cannot be entirely lost from that point - A "git rebase abort" is not like rolling back a transaction, it is more like a "git reset --hard" that will delete any new files that were added during that rebase. Git does not track what changes you did during your rebase, so it cannot "undo" them or roll them back. During the rebase, you're in a no-man's-land, and aborting the rebase is a git reset back to a previous commit node.

To re-summarize the problem - I made a handful of changes, and was organizing them into separate commits, 1 feature per commit. Halfway through, I realized I had missed some files on an earlier (unpushed) commit. I did a git stash, started an interactive rebase, did a git stash pop, added the missed files to a previous commit, and realized I had added the new files to the wrong commit node. Then, I did a git rebase --abort, which deleted those new files, and was generally horrible.

TLDR: Do not add new files during an interactive rebase without first backing them up - if you abort the rebase, your files will be (mostly) lost, and not easily recoverable.

like image 169
chaqke Avatar answered Oct 13 '22 10:10

chaqke


Since the files were never added to the DAG, it does not look like it's recoverable unless you have a second copy of them somewhere. If you added them to the index, however, you will be able to find them through, as @jefromi suggests, git fsck --lost-found.

More info:

Looking at reflog will show you where your branch pointed to before. You want to use git log to the the actual history. Add the --stat option to see the file changes at each commit.

like image 34
Adam Dymitruk Avatar answered Oct 13 '22 09:10

Adam Dymitruk