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

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

-Peff