On Fri, Dec 02, 2016 at 05:37:50PM -0500, Jeff King wrote: > On Fri, Dec 02, 2016 at 06:02:16PM +0000, thomas.attw...@stfc.ac.uk 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. >
There seems to be another issue, which may or may not being related: https://github.com/git-for-windows/git/issues/979 This is pure speculation: Could it be that a '/' is lost because of a change in the underlying Msys2 between 2.10 and 2.11 ? Dscho, (or anybody else) any ideas?
