5

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.

BT101
  • 3,666
  • 10
  • 41
  • 90
  • Perhaps a duplicate of https://stackoverflow.com/q/1115854/5784831? – Christoph Sep 15 '19 at 14:52
  • There's no info about this ref 'HEAD'. I deleted .git/index and run git reset but I still got error I don't know what to do I think I'll need to create new repo and push my local changes but I'll lose my commits history branches pull requests etc... – BT101 Sep 15 '19 at 17:15
  • How about this https://stackoverflow.com/q/39057962/5784831? There are some good suggestions for analysis. Perhaps this helps... – Christoph Sep 15 '19 at 17:54

4 Answers4

5

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.1 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.

1This 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.

torek
  • 448,244
  • 59
  • 642
  • 775
  • I don't use dropbox and my SSD seems to be working fine, that's mysterious – BT101 Sep 15 '19 at 22:35
  • Can you tell why this error occurs automatically ? I didn't do anything , was working yesterday and now doesn't. – Badri Paudel Jun 10 '21 at 17:51
  • @BadriPaudel: no, it requires manual investigation and/or situational knowledge (e.g., "oh, the power dropped out yesterday and the system had to reboot and ate a few files when it did that" or "the administrator moved everything from one disk drive to another yesterday" or whatever). – torek Jun 11 '21 at 05:07
  • Thanks for the hint to Dropbox as possible cause. I just had this problem with a git repository inside OneDrive. When viewing the content of .git with the Windows explorer it says: "Location is not available - [...]\.git\refs is not accessible. The tag present in the reparse point buffer is invalid." – phispi May 06 '22 at 06:59
1

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.

websplee
  • 187
  • 1
  • 7
1

try this

 git remote set-head origin --auto

Sets the default branch (i.e. the target of the symbolic-ref refs/remotes//HEAD) for the named remote. Having a default branch for a remote is not required, but allows the name of the remote to be specified in lieu of a specific branch. For example, if the default branch for origin is set to master, then origin may be specified wherever you would normally specify

:)

Max Roa
  • 499
  • 4
  • 4
0

if you are doing in linux you can remove the index (make a backup copy if you want), and then restore index to version in the last commit

rm -f .git/index

git reset

GAURAV KUMAR
  • 75
  • 8