Hi Lyle, On Thu, 27 Feb 2020, lyle.ziegelmiller@xxxxxxxxx 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@xxxxxx> > Sent: Thursday, February 27, 2020 1:05 PM > To: Jeff King <peff@xxxxxxxx> > Cc: brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx>; > lyle.ziegelmiller@xxxxxxxxx; git@xxxxxxxxxxxxxxx > 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@xxxxxxxxx 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 > > > >
