Git Cannot lock ref 'HEAD'

Question

I made some commits yesterday but didn't push them. Today I woke up I tried to push it and I had

error: bad index file sha1 signature fatal: index file corrupt

I tried to:

$ del .git\index
$ git reset

and then tried to push my commits once again but it fail and now I have

fatal: cannot lock ref 'HEAD': unable to resolve reference 'refs/heads/light-mode': reference broken

What's going on? I don't want to lose my commits but more important I don't want to lose my local changes into project.

Answer 1

Your Git repository has been damaged. It's not possible to say by what or by whom at this point. A common culprit is using Dropbox or similar to store the .git directory.¹ A less-common culprit is actual hardware failure, e.g., your spinning-rust disk or SSD is failing.

This message:

fatal: cannot lock ref 'HEAD': unable to resolve reference
'refs/heads/light-mode': reference broken

occurs because your current branch, light-mode, has its hash ID stored in either .git/packed-refs or .git/refs/heads/light-mode. One or both of these files either contains garbage, or no longer contains the hash ID of a valid commit. Again it's not really possible to guess which files have which specific problems, nor what programs or hardware failures caused them. The work you did may have been damaged or destroyed irretrievably.

If you know the correct hash ID of the commit you made yesterday, you can attempt to recover that hash ID using, e.g., git checkout hash. If all else fails, you can run git fsck --lost-found: for each hash ID for which Git prints dangling commit or dangling blob, Git also saves the contents of that commit or file into .git/fsck/lost-found: look at the commits and other folders. The other folder will contain the found files' data. The names of those files are no longer available, but you might recognize some important content and therefore be able to say: aha, that's the important file I wanted back and get it back that way.

---

¹This is a very bad idea in general, because Dropbox and Git fight over who will control specific files' specific contents. It can work for a while, leading to a false sense of security. Then—usually right before an important presentation or a class deadline or whatever—boom, Dropbox decides that six critical Git files should be rolled back to some previous version, and your work is gone.

Answer 2

I had a similar experience and for me the issue is that I use Git Bash as well the inbuilt Visual Studio Git plugin.

What worked for he was deleting the branch file in the following location .git/refs/heads/branch_name

Then I went back to Git bash and executed the following command git reset and I was good to go.

Lesson for me I think is, going forward I will use Git Bash all the way.