0

I looked at many other questions to no avail.

My laptop froze during git reset --hard or git checkout branch. Not sure. After the hard reset I see

$ git fsck
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

I saw that .git/index was an empty file. Deleting it yields no results.

Any ideas how to restore? I have most my stuff pushed to a remote but I prefer to keep my branches and stashes. I have some useful stuff in there and even if I can track most of it remotely, would be hard.

akostadinov
  • 17,364
  • 6
  • 77
  • 85

1 Answers1

2

I figured it out. Also my .git/HEAD file was empty. I've put inside it

ref: refs/heads/master

Then I've run (be careful with these, in case you had uncommitted changes, you can copy your modified files safely somewhere else first).

git reset --hard
git clean -f

I found out what the issue is by running strace git status and noticed that it tries to find HEAD file in the directory path. Then it was easy.

P.S. after the fact I see that my branch where I tried to do git reset --hard another_branch is missing. So apparently issue happened while doing reset.

akostadinov
  • 17,364
  • 6
  • 77
  • 85
  • The lack of a valid `.git/HEAD` file will prevent Git from recognizing the repository as a repository, yes. There are several other conditions that will do it, such as a missing `.git/objects` directory, but the `HEAD` file is a simple file and it's relatively easy for it to be damaged by a computer crash. `git reset --hard` *should not* damage it; if it does, that generally indicates a bug in the Git code, as it's supposed to figure out that something has gone wrong and put the old `HEAD` back. – torek Feb 09 '22 at 02:37
  • @torek, actually it could have been `checkout`. I assume `HEAD` is replaced during `checkout`. So if the crash happened while it has been truncated, then it couldn't be written to with correct data. WDYT? I will edit my answer if this sounds plausible. – akostadinov Feb 10 '22 at 09:54
  • Checkout typically has to overwrite `HEAD` with new contents (replacing `ref: refs/heads/br1` with `ref: refs/heads/br2` for instance). Git tends to use the "write new file, rename into place" technique (though it's not 100% consistent here). If you're allowed to delete a file, but not create a new one, that would do it, but that's a weird permission setup... – torek Feb 10 '22 at 21:57