On Fri, Dec 02, 2016 at 06:02:16PM +0000, thomas.attwood@xxxxxxxxxx wrote: > 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). > 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