Re: Having an invalid HEAD file causes git not to recognize the repository

From: Jeff King <peff@peff.net>
Date: Aug 21, 2012, 07:24 UTC
Message-ID: <20120821072403.GD3238@sigill.intra.peff.net>
In-Reply-To: <CANtNKfp+9HpvWkAO0vrm84oMiJNvjFg9T-UtNQko+ABHhEWj6w@mail.gmail.com>

On Fri, Aug 17, 2012 at 02:42:33PM +0300, Egon Elbre wrote:

Show 5 quoted lines

> Having an invalid HEAD file causes git not to recognize the repository
> and will cause an invalid message "fatal: Not a git repository (or any
> of the parent directories): .git" although there is a .git folder and
> everything seems okay in it. Solution was just to change HEAD to a
> valid ref/hash.

Right. When we search for a .git directory, we do a few sanity checks on each candidate, like whether it has a properly-formatted HEAD, and whether it has "objects" and "refs" directories. We have to balance these heuristics to avoid false negatives (like yours, when the directory was meant to be a repository but looked bogus) with false positives (when we accidentally treat some random directory like a git repository).

Since you don't have a working repository, the best we could do is say "well, this looks like a repository, but it's broken, so I kept looking". I think the best approach would probably be to have a new GIT_TRACE_GITDIR environment variable to help debug git-dir lookup (i.e., to print out details of the search as it happens).

> I ran into this problem when I had a BSOD during a rebase (ignore that
> I'm having to use Windows). This meant that only half of the hash got
> written into HEAD and all git commands I tried failed.

That generally shouldn't happen, as we write new ref content to a temporary file and then rename it into place atomically. I wonder if there is a problem with the atomicity there (we do not fsync after close, which some filesystems might want), or if it was simply filesystem corruption related to your BSOD.

-Peff