Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

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.
                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, 2019 at 17:15
                How about this stackoverflow.com/q/39057962/5784831? There are some good suggestions for analysis. Perhaps this helps...
– Christoph
                Sep 15, 2019 at 17:54
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.
                Can you tell why this error occurs automatically ?  I didn't do anything , was working yesterday and now doesn't.
– Badri Paudel
                Jun 10, 2021 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, 2021 at 5: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 6, 2022 at 6:59
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.
                Do you mean if you use integrated terminal in IDE instead of git bash, it may create problem ?
– Badri Paudel
                Jun 10, 2021 at 17:53
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
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
                if still you are getting same error make a backup copy and reset git repo git reset --hard head  git clean -f  git pull  git checkout branchname
– GAURAV KUMAR
                Sep 15, 2019 at 14:58
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.