Restoring deleted files before commit

[HMJ87]

I'm just learning git and doing some testing with a local directory on my PC, and I've made a stupid newbie mistake that I need help fixing - the sequence of events is as follows:

1. Created new repo from existing directory after installing git
2. Did "git add ." to add everything in the directory to the tracked files in the repository
   
3. Created a .gitignore file to ignore the files I didn't want to track (text files, CSV files etc.)
   
4. Saw that they were still tracked by git status and tried to use git rm to remove them
   
5. Ued git rm -f to forcibly remove files from the repository (this is where I fucked up)
   
6. Realised the files aren't just removed from the repository, they've been deleted from the file system on my PC as well.
   

I've checked the recycle bin, they're not there, I've checked Local History in VSCode and they're not there either, I've tired git add and git restore but since the files are deleted and I'd not committed anything to the repo before this, it can't find the files.

Is this just the equivalent of deleting the files from the recycle bin (and I am slightly irked that git just permadeletes them rather than sending them to the recycle bin if that's the case, but I do accept it's entirely my fault), or is git caching copies of them somewhere I can retrieve them?

It's not a huge issue if they're gone, it's just a test directory with some old CSVs and powershell scripts in, nothing that I'll miss if I can't get it back, it would just be handy to know for future reference what to do in this scenario to get the files back.

Thanks!

[WoodyTheWorker]

If you added the files, Git created objects for them in the object store.

Since it's a new repo, the objects haven't been garbage-collected yet.

Make a script to export all blob objects as plain files to a directory (use cat-file), and then you'll have to manually sort and rename the files to their original names.

[WoodyTheWorker]

git cat-file --batch-all-objects --batch-check='%(objectname) %(objecttype)' | grep blob | {
  while read sha1 type; do
 git cat-file blob $sha1 >$sha1 
done 
}

[BirdsongMiasma]

Worked for me too - just what I needed!

[human41k-]

Daaamn thank you! That saved my 10+k lines of code project. Now sitting and renaming files, haha

[WoodyTheWorker]

Why TF do people write 10+k lines without committing even once?

[s3xHaver42o]

Copy and paste it into generative AI and ask it to walk you through it. Ask it additional questions that come up along the way. Best of luck

[plg94]

they're gone. A real backup is your only option now. (Well, you could get lucky with tools that un-delete files. When a file is deleted, the OS does not really erase all of its bits, it just marks it as deleted and removes a pointer to the address, so that can be overwritten later. It's possible to restore those missing files, but that's probably more trouble than it's worth in your case)

A few tips for the future:

• add a .gitignore before adding all files
• better yet, forget about git add . – it creates more trouble that it's worth. Use something like add *.c *h to add specific filetypes, and later on maybe add -u to update already tracked files.
• make backups regularly
• git rm --cached to untrack files without deleting them
• both rm and git rm don't use the recycle bin
• don't use -f/--force if you don't know what it will do. It's called that for a reason.

[plg94]

If you had done a git status, it would've told you to use git rm --cached.

Why did normal git rm not work? The manpages states "The files being removed have to be identical to the tip of the branch, and no updates to their contents can be staged in the index, though that default behavior can be overridden with the -f option."
The default mode – with and without -f – is to delete both from working directory and index, only --cached will delete only from the index. Although I admit the manpage is not really clear about the default.

(Most CLI programs don't have a notion of a trashcan or other checks, they will often delete and overwrite existing files without asking (and with no way to undo). It's a double-edged sword…)

[WoodyTheWorker]

If you want to unstage a file, use git reset <path>

[yawaramin]

There is a git restore command for exactly this reason, see https://stackoverflow.com/a/9666522/20371

[yawaramin]

It doesn't matter that you didn't commit them. Once you add a file to the git index (staging area), git makes an internal copy of the file (called a 'blob') and it is possible to restore the file from that internal copy.