Re: ! [remote rejected] master -> master (unpacker error)

From: Jeff King <peff@peff.net>
Date: Feb 18, 2020, 05:19 UTC
Message-ID: <20200218051956.GA1641086@coredump.intra.peff.net>
In-Reply-To: <20200216211604.GE6134@camp.crustytoothpaste.net>

On Sun, Feb 16, 2020 at 09:16:04PM +0000, brian m. carlson wrote:

Show 22 quoted lines

> On 2020-02-16 at 16:10:12, lyle.ziegelmiller@gmail.com wrote:
> > Hi
> > 
> > Any updates on this error I emailed a while back?
> > 
> > lylez@LJZ-DELLPC ~/python
> > $ git push
> > Enumerating objects: 5, done.
> > Counting objects: 100% (5/5), done.
> > Delta compression using up to 4 threads
> > Compressing objects: 100% (2/2), done.
> > Writing objects: 100% (3/3), 279 bytes | 23.00 KiB/s, done.
> > Total 3 (delta 1), reused 0 (delta 0)
> > remote: fatal: not a git repository: '.'
> 
> This error is telling you that Git doesn't think the remote location is
> a Git repository.  It could be because it really isn't one, or it could
> be that the permissions are wrong.
> 
> It could also be that the repository is mostly there but very slightly
> corrupt and therefore can't be detected as one.  For example, it could
> be missing its HEAD reference.

I think it's more subtle than that, though. If it wasn't a git repository at all, then receive-pack would fail to start, and you'd get something like this:

  $ git push /foo/bar
  fatal: '/foo/bar' does not appear to be a git repository
  fatal: Could not read from remote repository.
  
  Please make sure you have the correct access rights
  and the repository exists.

The output above, plus the:

  error: remote unpack failed: unpack-objects abnormal exit

makes it looks like receive-pack started just fine, but something about the way it set up the environment made the child unpack-objects unhappy when it tried to initialize its internal repo variables.

I have no clue what that "something" is, though. Windows and UNC paths were mentioned elsewhere, which seem plausible. It mentions ".", so presumably we've chdir()'d into the receiving repository and set $GIT_DIR. Which I'd think rules out any weird interpretations of UNC paths in $GIT_DIR.

I'd expect that error if we did a chdir() internally to some other path after setting up $GIT_DIR, but I don't know why we'd do that (I thought at first that the quarantine code in receive-pack might be related, but we don't ever chdir() into the quarantine dir; we just set up GIT_OBJECT_DIRECTORY).

-Peff