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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Lyle,

On Thu, 27 Feb 2020, lyle.ziegelmiller@gmail.com wrote:

> " 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?"
>
> I'm using the latest version of Windows 10 and Cygwin's version of git -
> version 2.21.0. This is being executed in a Cygwin window, not a DOS
> terminal.

I was talking about Git for Windows, not about Cygwin Git.

Ciao,
Johannes

> All of this stuff used to work.
>
> Regards
>
> Lyle
>
> -----Original Message-----
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Sent: Thursday, February 27, 2020 1:05 PM
> To: Jeff King <peff@peff.net>
> Cc: brian m. carlson <sandals@crustytoothpaste.net>;
> lyle.ziegelmiller@gmail.com; git@vger.kernel.org
> Subject: Re: ! [remote rejected] master -> master (unpacker error)
>
> Hi Peff,
>
> On Tue, 18 Feb 2020, Jeff King wrote:
>
> > 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
>
> > 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
> >
>
>