1

I tried to remove a file from git before initial commit using git rm, but it didn't work because it was a folder so I used git rm -rf <file>
Unfortunately, this has left me with no commit history of the file, and it appears to have been deleted locally as well. I went to my trash and it's also not there. This is honestly making me terrified of git and I don't know how to fix it. I can technically live without it, but it was all the source files for a website I made, which makes my life hard. Is there anyway to recover them/generate a src folder from a dist folder, though I highly doubt that?

Mr Lister
  • 45,515
  • 15
  • 108
  • 150
Tim Gass
  • 383
  • 3
  • 9
  • Note that you only removed it in one commit, all other commits still contain the file (so no history is gone) – Ikke Jan 29 '16 at 23:36
  • 2
    You say "before initial commit" ? Do you mean that any files in this folder had never been committed before ? Also can you clarify "no commit history of the file" ? `git rm` does not modify any history. – Willem D'Haeseleer Jan 29 '16 at 23:38
  • Yes. I needed to use more characters. Weird. – Tim Gass Jan 29 '16 at 23:42
  • 1
    It seems like your fear should be directed at your shell. If you expect removed files to appear in the "trash", then you should not be using a shell. That, or you should educate yourself on how a shell works. – William Pursell Jan 30 '16 at 00:14

3 Answers3

1

Your Problem

If I understand correctly, you had added your files like so:

git add my_dir/*

and before committing them, you removed everything like so:

git rm -fr my_dir

after which everything was gone indeed.

Your Solution

To solve this, proceed like Ikke suggests below:

git fsck --lost-found

And look for lines about "dangling blobs" (your lost files hopefully), like this one:

dangling blob 3a9b15a451d1e77aa262f3379dfb20d235b6f9d4

These dangling blobs will not have any information about the names of your lost files, but should've retained their content nevertheless.

Investigate each blob and recover the content like so:

git show 3a9b15a451d1e77aa262f3379dfb20d235b6f9d4 > my_dir/original_file

References

See also the answer of Alexander Gladysh here: In Git, how can I recover a staged file that was reverted prior to committing? and that of Vi. here: Recover dangling blobs in git.

Community
  • 1
  • 1
Ytsen de Boer
  • 2,797
  • 2
  • 25
  • 36
  • Unfortunately, I got no dangling bobs. However, I ran it on a localhost server, and it seems to have been cached from that, mostly. So, I luckily got most of my files back. That being said, I have been looking into backup options and I'm wondering what is the best way to go. The two options that I've explored are backing up my files in atom or backing up my files in gulp. I can do either, but I'm not sure which is best. – Tim Gass Feb 01 '16 at 03:18
  • Hm, in that case the formulation of your question must be somewhat off, since "git rm -fr" does not remove files that have never been added. Unfortunately I cannot help you with your question about back-up options. – Ytsen de Boer Feb 01 '16 at 14:25
0

To get that folder back, you need to find the last commit that still had it.

Let's imagine it's the second last commit. Then you can recover that folder with:

git checkout HEAD~1 <folder>

HEAD~1 is the reference to the second to last commit. If it's an even older commit, you can increase the number.

Executing this command will get the contents of that folder from that commit and put it in you worktree.

Edit:

You say you never even comitted that file? Then there is indeed no history of it in git, because you never asked git to keep any history.

Did you ever execute git add on that folder? Then the files are still stored in git, though, it's not easy to get them back into files.

You can use git fsck --lost-found to let get search it's object store for unreferenced objects, and it will store them in .git/lost-found.

For blobs, they will be stored in .git/lost-found/other. Inspect those files there and see if you find the ones you are missing.

Ikke
  • 99,403
  • 23
  • 97
  • 120
  • But the last commit was no commit, because I removed the files before initial commit. :( Methinks I am screwed. – Tim Gass Jan 29 '16 at 23:40
  • Yes, unless you did something like git add on the files, the files are indeed gone. See also my edit. – Ikke Jan 29 '16 at 23:42
  • Yes, I did git add . and it added the source, which I did not want it to do, which is why I used git rm -rf to removed them after I added them. – Tim Gass Jan 29 '16 at 23:43
  • Also, is there a tool or something I could use to prevent this in the future? I was considering adding like gulp-history or something to have another backup, just in case. – Tim Gass Jan 29 '16 at 23:44
  • I rangit fsck --lost-found, but unfortunately, I could not find any such file in my .git folder. It did say `Checking object directories: 100% (256/256), done.` but that was it. Perhaps Git doesn't know about the changes? If I am too noob to be able to perform what you are asking on my end, I don't want to waste too much of your time. It didn't find anything. Let me know, if you know another way. Thanks for all your help! – Tim Gass Jan 30 '16 at 00:03
-1

First off, be aware of the git reflog, which logs not just commits, but no-longer-visible states of git. Pretty much anything that git actually knows about will be in there. Check there if you have some doubts.

Secondly, back up your current directory. Copy the whole directory with git somewhere. Git may already have your back, so this is rarely necessary once you're used to git, but as a newbie, it gives you the confidence to do whatever you need to "unbreak" the working copy without worrying about making things worse.

Ok, so you have a backup of whatever broken or not broken state you created, now you can work on the copy with confidence to figure out what you did. git reflog and then git branch sOmEhAsH, see if it's what you want and need. Get the commit and the uncommitted files that you want, and then commit untracked stuff until you're satisfied.

Now, finally, you have to consider whether the push you made is public. If it is public, and anyone could possibly have already or in the future pulled that commit, you'll git revert sOmEhAsH and undo your mistake. If no-one else could possibly have received the bad commit, you can do the !destructive! action of a forced push, via the destructive git push -f which will push up whatever you have in the current branch, regardless of what it needs to overwrite in the remote branch. Use that with care, it's generally not recommended to use on any shared branch.

Kzqai
  • 22,588
  • 25
  • 105
  • 137
  • OP pointed out he never committed the files in the first place. reflog won't help here. Even if he had commited, reflog is not the right approach here, he can just checkout or reset to an older commit. – Willem D'Haeseleer Jan 29 '16 at 23:43
  • The reflog only tracks references to `HEAD`. This means only when you commit something, or execute some other command that moves HEAD, it will be updated. It will not track the index, nor any random objects. – Ikke Jan 29 '16 at 23:44
  • Yeah, that's what I noticed. I haven't seen any ways posted online about how to revert to git init state or changes processed before initial commit. I am in a pickle. – Tim Gass Jan 29 '16 at 23:46
  • Indeed! I mis-spoke when I said uncommitted, blah. I meant **not-immediately-visible**. The point is that once you know about `git reflog`, and have a backup of your broken directory, you know what kind of trouble you're in for. If it's not in the reflog, you didn't commit it, so you have to deal with the problem from that perspective. – Kzqai Jan 29 '16 at 23:55
  • And what does dealing with the problem from that perspective entail? Does that mean it is not stored, or that I just have to find it differently? Also, why would the file not appear in trash? – Tim Gass Jan 30 '16 at 00:06
  • @TimothGass In `git reflog` -> you're golden, which is why it's the first place to look. Otherwise, you're mostly dealing with a case of having `-f` **force** deleted a never committed file. If it's no longer in your current directory *as a regular untracked file*, Ikke's suggestion to go fishing for git file blobs may be your only recourse, I've never used those commands personally. – Kzqai Jan 30 '16 at 00:23