Re: git 2.11.0 error when pushing to remote located on a windows share

From: Jeff King <peff@peff.net>
Date: Dec 2, 2016, 22:37 UTC
Message-ID: <20161202223749.2n7wa37e5w6446uv@sigill.intra.peff.net>
In-Reply-To: <AABB04BF1441D24CB4E9FCF46394F17D666F34E1@exchmbx01>

On Fri, Dec 02, 2016 at 06:02:16PM +0000, thomas.attwood@stfc.ac.uk wrote:

Show 16 quoted lines

> After updating git from 2.10.0 to 2.11.0 when trying to push any
> changes to a repo located in a windows share, the following error
> occurs:
> 
> $ git push origin test
> Counting objects: 2, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (2/2), done.
> Writing objects: 100% (2/2), 284 bytes | 0 bytes/s, done.
> Total 2 (delta 1), reused 1 (delta 0)
> remote: error: object directory /path/to/dir/objects does not exist; check .git/objects/info/alternates.
> remote: fatal: unresolved deltas left after unpacking
> error: unpack failed: unpack-objects abnormal exit
> To //path/to/dir
>  ! [remote rejected] test -> test (unpacker error)
> error: failed to push some refs to '//path/to/dir'

Hmm. This is probably related to the quarantine-push change in v2.11; the receiving end will write the objects into a temporary directory but point to the original via GIT_ALTERNATE_OBJECT_DIRECTORIES. That pointer isn't working for some reason, so the receiver can't resolve the deltas it needs.

As you noted, the extra "/" is missing in the error message, and that sounds like a plausible cause for what you're seeing. I'm not sure where the slash is getting dropped, though. The value in the environment comes from calling absolute_path(get_object_directory()), so I suspect the real problem is not in the quarantine code, but it's just triggering a latent bug elsewhere (either in absolute_path(), or in the code which generates the objdir path).

Show 10 quoted lines

> No error occurs if pushing to the same repo (a direct copy into a local directory) using 2.11.0.
> 
> $ git push local_test test
> Counting objects: 2, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (2/2), done.
> Writing objects: 100% (2/2), 284 bytes | 0 bytes/s, done.
> Total 2 (delta 1), reused 1 (delta 0)
> To C:/path/to/dir
>  * [new branch]      test -> test

The fact that it works using the non-UNC path reinforces my feeling that something is normalizing the absolute path incorrectly.

> Using `git fsck --full` in both 2.11.0 and 2.10.0, it doesn't reveal any additional problems.

Yeah, I don't think there is anything wrong with your repo. It's just a path-building issue internal to the receiving process.

-Peff