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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 27, 2020, 21:04 UTC
Message-ID: <nycvar.QRO.7.76.6.2002272204150.46@tvgsbejvaqbjf.bet>
In-Reply-To: <20200218051956.GA1641086@coredump.intra.peff.net>

Hi Peff,

On Tue, 18 Feb 2020, Jeff King wrote:

Show 48 quoted lines

> On Sun, Feb 16, 2020 at 09:16:04PM +0000, brian m. carlson wrote:
>
> > On 2020-02-16 at 16:10:12, lyle.ziegelmiller@gmail.com wrote:
> > >
> > > 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 thought that I remembered that it is not possible to `chdir()` into a UNC path. And it would seem that `cmd.exe` still cannot have a UNC path as a current directory.

But PowerShell can, and so does `git.exe`, apparently (I tested this using `wsl bash -lc "cd ~ && git.exe -C . version"`).

But I vividly remember that there used to be a problem even with `git.exe`, probably still is a problem on older Windows versions. That might be the problem here?

Ciao, Dscho

Show 8 quoted lines

> 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
>