1

I forgot to add .ai to my .gitignore file, but ran $ git add . and added quite some .ai files to the index.

When I ran $ git status and saw them, I wanted to remove them from the index.

In haste, I ran $ git restore -s@ -SW resulting in all of my .ai files are gone away from my working tree. I should not have used W.

Is there any way in which I can get my .ai files back?

Sherman Chen
  • 174
  • 9
  • 1
    If you never committed them, and you have no backup, then sorry, no. – Inigo Jul 09 '21 at 02:28
  • 2
    @Inigo If they added it to the index, they're in the object folder. If they were never committed, they are still there as dangling objects. – Lasse V. Karlsen Jul 09 '21 at 07:58
  • @LasseV.Karlsen I always assumed that objects were only created upon commit (stashes being like a commit internally). But thinking about it what you say makes total sense (how else would git track index entries?) So I just learned something. Thank you! Upvoting VonC's answer :) – Inigo Jul 09 '21 at 08:04
  • 1
    What is -DW? I doubt you ever said that. Maybe you said -SW. – matt Jul 09 '21 at 08:35
  • Sorry. You are right. I did -SW – Sherman Chen Jul 09 '21 at 11:52
  • 2
    @Inigo `git add` adds objects to the object db. The index is an index, object ids for interesting paths. – jthill Jul 10 '21 at 01:28

1 Answers1

6

First, check if you still have access to those files through the "local history" (as recorded by your IDE, not Git)

For instance, the Local History VSCode extension, as suggested here, can help.

If not, double-check your OS backup feature, like for MacOS Time Machine status, in case you could restore them from a backup.

Finally, since you have added those files to the index, check git fsck

git fsck --cache --no-reflogs --lost-found --unreachable HEAD

From the SHA1 listed, you can do a git show:

git show "<SHA-1 REFERENCE TO THE BLOB OBJECT HERE>" > lost_file.txt

As noted by torek in the comments:

Note that you can also find the contents of each of those "unreachable blob"s in the .git/lost-found/other directory.

This is often quicker and easier than git show since you can cd .git/lost-found/other, and then grep expected-string * to find the file(s) that have the expected string.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thank you very much for your answer, VonC! I use vim, and did not use any IDE. I did not set up backup on my Windows 10. I ran the git fsck command you recommended, and got the following result. What can I do next, please? – Sherman Chen Jul 09 '21 at 12:17
  • @ShermanChen No problem: did you manage to restore those files? – VonC Jul 09 '21 at 12:18
  • $ git fsck --cache --no-reflogs --lost-found --unreachable HEAD Checking object directories: 100% (256/256), done. unreachable blob 0ec003e3d01171ac5e34fa1004b35f8ec75ca598 unreachable commit 71517cfc137a01064a260786891d0b30c8e3e639 unreachable blob ea822e0644c310f5217c0adf5bb2aa56f4ad320d unreachable blob 86136a72fe190dc1b38f28e83feb83e6433f5b19 unreachable blob 4344ae85545d6f772c50f0a9706dcd2c31d33027 unreachable blob db650a29ec44871ded5972249c6b921de9460bda unreachable blob f9b55969b1d8665184a1de04d1de98e4e43e6230 unreachable blob 7f5679c6af24e68cb2f5ba609129fb7b954b8856 – Sherman Chen Jul 09 '21 at 12:22
  • @ShermanChen See https://stackoverflow.com/a/63435475/6309 to restore files – VonC Jul 09 '21 at 12:28
  • 1
    Oh my God! I have got back one of the lost files. That is a miracle! Thank you soooooooooooooo much for your kind help, VonC!!! A 'show' command has done much much more than a 'show'! It has greatly restored from a wrong 'restore'! I did not expect that those files could be found back. I posted my question just for possibly a bit hope. How can I buy at least a coffee for you, VonC? – Sherman Chen Jul 09 '21 at 13:26
  • 1
    @ShermanChen Great job! I have edited the answer to add the `git show` – VonC Jul 09 '21 at 13:28
  • 1
    VonC, Your great answer will help countless people! – Sherman Chen Jul 09 '21 at 13:40
  • 1
    @ShermanChen: Note that you can also find the contents of each of those "unreachable blob"s in the `.git/lost-found/other` directory; this is often quicker and easier than `git show` since you can `cd .git/lost-found/other` and then `grep expected-string *` to find the file(s) that have the expected string. – torek Jul 09 '21 at 18:04
  • 1
    @torek Thank you for this option. I have included your comment in the answer for more visibility. – VonC Jul 09 '21 at 18:06
  • @torek there is no .git/lost-found/ directory. – Sherman Chen Jul 10 '21 at 01:12
  • @ShermanChen: With `git fsck --lost-found`, Git should make one and populate it. Perhaps `--unreachable` disabled this, but I don't think it should. – torek Jul 10 '21 at 01:40
  • @torek Oh. I do not know why, but there is not. – Sherman Chen Jul 10 '21 at 01:43
  • @ShermanChen What Git version are you using? And on which OS (name and version)? – VonC Jul 10 '21 at 08:05
  • @VonC git version 2.31.1 windows10 Pro version 21H1 – Sherman Chen Jul 10 '21 at 10:23
  • @VonC @torek I have installed git version 2.32.0.windows.2 just now, and run `git fsck --cache --no-reflogs --lost-found --unreachable HEAD` again. There is still no `.git/lost-found/` – Sherman Chen Jul 10 '21 at 11:13
  • @torek I understand that that [`--lost-found` implies `--no-reflogs`](https://stackoverflow.com/a/66405506/6309) (and the documentation update attempt [is not going well](https://github.com/git/git/pull/970#issuecomment-788196473)), but I tried a `git add aFile`, `rm aFile`, `git restore -s@ -SW` (status clean), and `git fsck --cache --lost-found --unreachable HEAD`, and... a [`lost-found` folder](https://git-scm.com/docs/git-fsck#Documentation/git-fsck.txt---lost-found) is nowhere to be, errr, found. – VonC Jul 10 '21 at 15:02
  • Curious. Might be a new bug in `git fsck`; I've actually used the whole lost+found thing a few times myself in the distant past. – torek Jul 10 '21 at 20:16