can i restore a .git file after rm-rf?

Question

I needed to pull the master branch but was having issues merging it into my local master and so thought it expeditious to simply rm -rf the entire folder. This was the great

Answer 1

.git is actually a folder containing your local repository. In deleting that you deleted your history.

If you removed only the repository (the .git folder) and not the parent source directory, the latest versions of your code files should still be present in the source directory. If you removed the whole source folder along with the repository you need to look at restoring files.

As you're on Windows, if you have no backup, system restore might be your only option.

• Right click on whatever parent folder you have (either the source directory, or if that's gone, the folder that contained it).
• Go to the Previous Versions tab and see if you have a previous version of the folder there.

You may not get a full recovery but if you have a recent image you may get some of your work back.

If you get no luck with that you'll need to do more research on file recovery. There are apps available. I'd recommend not writing to the disk any more than you have to (preferably not at all) if that is the route you need to go.

Answer 2

If you are using windows backup please visit https://support.microsoft.com/en-us/help/17119/windows-7-recover-lost-deleted-files

Answer 3

Alright, so all hope is apparently lost for my git history (the .git file that I foolishly obliterated) -- HOWEVER! All hope has not ultimately been lost because following the sage advice of Lincoln Spector, I was able to recover all of my deleted working directories, most of which were in their most current state, and the rest of which (and I'm still incredibly grateful for these) were just a couple of days out of date. Recuva Portable, which was just one strategy recommended there, has just saved me several days of work and several million strands of hair.

Thanks for all the answers. I'm just throwing this in because the best I got told me to use System Recovery/Windows Backup/restore points of some form or another which would have been great if only I'd been using those features prophylactically. Alas, I was not. So I had to go the dirty route. So if anyone is smart enough to have already been using those features, by all means go the routes offered in the other answers, especially by Tone. If anyone is like me and failed both in the past and present, Recuva worked great.

Answer 4

I want to share my similar experience and give some hope.

Background

At my company we have yet to migrate to git and still use TFVC for version control. Since git is vastly superior at everything, I've started using a local git repository for my work. The workflow is basically using git as a draft workspace and then committing to TFVC in chunks when things are ready. The problem is that my git repository is local only.

The procedure

To check-in to TFVC I keep a sync branch that I keep in sync with the TFVC branch. So I have local git branch feature-1, feature-2 etc. Then I checkout my sync branch. Make sure it's sync to TFVC, merge the git stuff I want to commit to TFVC into sync, commit to TFVC.

The problem

It's hard to describe the pain and suffering caused by TFVC without utterly bashing on the people that created it to what I at least hope were their best intensions. Let's just say that git is in my opinion an excellent piece of software and my experience working with TFVC hasn't exactly been pleasant.

To have control over my commits (and because TFVC is less than excellent) I start the procedure by syncing my local workspace with the server. To do that you use the command tf reconcile with the option clean, essentially "take the server workspace". Now, my git repository resides inside the TFVC repository (misstake). The good folks behind TFVC decided that the the suitable default for tf reconcile /clean was to clean ignored files (??). Usually, this is not a problem because you get a lovely(/s) GUI(???) that prompts you the files to be cleaned.

Maybe you are a person that likes the terminal to not good, in which case you probably use something like Power Shell. Or maybe you like it to be god-awful and so you use the Command Prompt. Me, I like bash. The problem is that for unkown reasons, in bash, the aforementioned prompt is not shown. I mean, you're in bash, so why would you want to open a stupid GUI window. Since the GUI wasn't shown, failed or whatever, what happens next is a piece of beauty. TFVC just proceeds.

The result

$ tf reconcile //clean
Deleting .git
$ git status
fatal: not a git repository (or any of the parent directories): .git

...

The solution

Thankfully, TFVC didn't nuke everything. It turns out it's nice enough to leave some things alone (what seems somewhat arbitrary).

After panicking, I downloaded Recuva, to try and unf**k what TFVC just did.

Turns out it was able to recover some files in the .git folder. A bunch of binary hash files but seemingly more importantly, files like HEAD.

I recovered the deletes files that could be recovered to a separate folder, on a separate drive (to avoid writing sectors). Then copied the original location to the recovered location (not overwriting). And voila:

$ git status
On branch main

Doing a diff with the original location yielded:

Only in .git: COMMIT_EDITMSG
Only in .git: config
Only in .git: config_1
Only in .git: description
Only in .git: HEAD
Only in .git: HEAD_1

Turns out TFVC left most of the repository intact and file recovery was enough to get the local repo up and running again. Some things seems lost, like the stash, but the work I had commited to branches in git but not in TFVC appears recoverable.

The takeaway

• Depending on what has been deleted and what can be recovered, it's possible that you can restore a deleted git repository. I imagine it depends on which files were deleted / are recoverable.
• Only use TFVC if you hate life

Edit

It may be possible to just run git init if as in my case, most of the git repo was left intact (or if most was recoverable)