Reputation: 11030
My computer shut down due to a kernal panic I lost my git repo on my virtual machine which is in Windows. When I go on .net I get the following error:
corrupted loose reference file: HEAD
I have in place a folder called .git that contains a list of my branches.
Is there a way I can convert this back to a git entity? Or would I have to reclone the directory?
Upvotes: 5
Views: 7186
Reputation: 3574
I fixed by doing the following:
Upvotes: 0
Reputation: 8920
You can set it to your previous stage without cloning the repository again. You might be able to keep your local changes, but you will lose all your unpushed commits or stashes.
This is what I would do:
rm -rf .git
)git init
git remote add origin <your remote repository url>
git fetch
git reset origin/<the last branch you were in>
This is important: If you were in the
Development
branch, then give it asorigin/Development
.
Now everything should be back in place. If you run git status
, you should see your modified files etc.
This is only a suggestion. You can copy your folder and give it a try and see :)
Edit: I have missed to include an important step. You need to fetch after you add the origin.
Hope it would work for you :)
Upvotes: 2
Reputation: 45659
What you're showing in your .git
directory is not a list of branches; it's the standard structure for git repo metadata. This includes a few symbolic refs, such as HEAD
. When a ref is stored as a file on disk, it's called a "loose" ref, which is what I believe the error message is talking about.
So the error seems to indicate that the file .git/HEAD
is corrupt. That in itself is not hard to fix (though most git commands won't work since they won't currently recognize that this is a repo, so it will take a bit of a kludge); the bigger question, in the wake of a sudden system crash, is whether anything else is also corrupt. But as a starting point, you might try something like
# back up .git/HEAD somewhere, just in case
echo 'ref: refs/heads/master` >.git/HEAD
Now hopefully your repo will be recognized again. Next it would be smart to do some checks like
git fsck
and maybe checking if you have expected changes on expected branches.
The most vulnerable thing would be uncommitted changes (and especially unstaged changes). But at least if the above steps go well, you can assess the damage and decide where to go from there.
Upvotes: 8