git status returns "fatal: Not a git repository" yet .git directory exists

Question

I have a remote folder that I am currently unable to push to. When I go directly to the remote directory and a do a 'git status' it reads:

fatal: Not a git repository

The .git folder does exists and it was working fine yesterday and nothing has changed since.

Can anyone tell me the reason(s) why I might receive this message even though the .git folder exists?

Thanks in advance for your help. Much appreciated!

Rodgerrodgers

missing rights on the .git directory ? – Electrical

If not what @Electrical suggests quite appropriately, possibly file system corruption... – Hollowell

what is the msg you get when to try to push? – Footfall

Thanks for your response. I've compared the permissions to another .git repository on the same server and they match exactly – Rodgerrodgers

The error I get when pusshing is as follows: fatal: '/var/www/vhosts/X.co.uk/httpdocs': unable to chdir or not a git archive Pushing to [email protected]:/var/www/vhosts/X.co.uk/httpdocs fatal: The remote end hung up unexpectedly – Rodgerrodgers

also can you run git --config -l and put the lines related to remote? – Footfall

Answer 1

If the permissions on the .git folder are fine, see that there is a file .git/HEAD existing or is not named wrongly like .git/head. The presence of .git/HEAD ( or HEAD in case of bare) is the secondary check for a git repository

Selfpity

If .git/HEAD exists and you still get this error, ensure that the content of .git/HEAD points to a valid reference. If git cannot parse the content, it also outputs that the repository is invalid. – Attenuate

what is .git/HEAD does not exist? (in my case only .git/ORIG_HEAD exists) and I'm having the same problem as the OP. – Paediatrician

@SeanAhrens I had a corrupted HEAD file, and a fine ORIG_HEAD file. Copying the latter over the former fixed my issue and got me back into a correct state. You could run git reflog to see recent HEAD positions once that's done, in case you need to reset to a different commit. – Airman

Probably a good idea to run git fsck --full after such a manual recovery, just to check if there's any corruption. – Airman

What can make git be unable to find the git repository even though the .git folder is there and the HEAD content is correct? I.e. what is the tertiary check? – Holyhead

Answer 2

Clone the remote repository into another folder and compare the .git folders. This will give you indication about missing or corrupted files. You'll probably see a difference in the objects folder that you can ignore.

Alternate

With such a test, differences in the objects folder are not necessarily a problem. – Airman

Correct, but in the other folders and files it may indicate what is the problem – Alternate

@DrewNoakes, I've updated my answer for your comment. Thanks! – Alternate

The content of several files may differ based upon what branch/commit was checked out, how many remotes there are, and what activity has been performed on the repo. HEAD, ORIG_HEAD, packed-refs, config, COMMIT_EDITMSG... these can all be different and not a sign of problems. I upvoted your answer because it's interesting, but I'm not sure what actionable information such a diff could give to someone looking to solve corruption. I came here when my repo was corrupted, and the tip around checking the HEAD file contains a valid SHA-1 was enough for me to fix my problem, thankfully. – Airman