Git push fail to a Windows share

Question

I\'m trying to push from my local repository to a remote repository located in a windows share.

I\'m going to recreate a simple scenario, where c is my local hard d

Answer 1

Had a very similar problem having a repo on a mounted Novell network drive. For me even git add . reported same error as yours. Installing the new version of Novell client completely solved the issue. I hope this helps someone who comes across this problem in the future.

Btw, using ip-adress or UNC-path of the drive did not help to solve the problem.

p.s. This is apparently a Novell-Windows-NTFS-MinGW issue only on a certain version of Novell. Here are details, if you are interested: http://git.661346.n2.nabble.com/Problem-pushing-to-a-Novell-share-td7248875.html

Answer 2

Using the IP address of the mapped network drive instead its UNC path or letter solved the problem.

git remote set-url origin //ip-address/share/central.git

Answer 3

You need to state which version of git (use the git version command). When I tried this with Git for Windows 1.8.3 (and also 1.8.4 and 1.8.5) it worked ok:

$ git remote add origin /z/ztest.git

$ git remote -v
origin  z:/ztest.git (fetch)
origin  z:/ztest.git (push)

$ GIT_TRACE=1 git push origin master
trace: built-in: git 'push' 'origin' 'master'
trace: run_command: 'git-receive-pack '\''z:/ztest.git'\'''
trace: built-in: git 'receive-pack' 'z:/ztest.git'
trace: run_command: 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress'
trace: built-in: git 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress'
Counting objects: 3, done.
trace: run_command: 'unpack-objects' '--pack_header=2,3'
Writing objects: 100% (3/3), 212 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: trace: built-in: git 'unpack-objects' '--pack_header=2,3'
trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all'
trace: built-in: git 'rev-list' '--objects' '--stdin' '--not' '--all'
trace: run_command: 'gc' '--auto' '--quiet'
trace: built-in: git 'gc' '--auto' '--quiet'
To z:/ztest.git
 * [new branch]      master -> master

As you can see, adding GIT_TRACE=1 before the command results in additional diagnostics being printed which can help pin-point failing parts of the push command.

In general I have tended to use the full UNC path rather than the assigned drive letter (eg: git remote add origin //MACHINE/Share/path/dir.git but you may be forced to use a drive letter if the path is really long.

UPDATE

Checking the git sources for the reported error shows this must be coming from sha1_file.c from a failed call to create_tmpfile in that file. In this function an attempt is made to create a temporary file called tmp_obj_XXXXXX (where the X's are replaced with something unique in git_mkstemps_mode()). If it was a permissions problem you would be getting a different message so for some reason it cannot create these temporary files on the remote drive (the error is in the unpacking part where the repository is the remote one). It tries up to 16384 times to find a unique name so the problem is likely in the directory path being used. I think you will need to compile Git for Windows and get a break point in the git_mkstemps_mode function in git/wrapper.c to find out what's going on. If you follow the installation instructions for msysGit then this will build it for you and you can try debugging.

Answer 4

With the next Git 2.12 (Q1 2017), you should be able to use a path (without having to use the IP address for referencing the server)

See commit 7814fbe (14 Dec 2016) by Johannes Sixt (j6t). ^{(Merged by Junio C Hamano -- gitster -- in commit 4833b7e, 19 Dec 2016)}

normalize_path_copy(): fix pushing to //server/share/dir on Windows

normalize_path_copy() is not prepared to keep the double-slash of a //server/share/dir kind of path, but treats it like a regular POSIX style path and transforms it to /server/share/dir.

The bug manifests when 'git push //server/share/dir master' is run, because tmp_objdir_add_as_alternate() uses the path in normalized form when it registers the quarantine object database via link_alt_odb_entries(). Needless to say that the directory cannot be accessed using the wrongly normalized path.

Fix it by skipping all of the root part, not just a potential drive prefix. offset_1st_component takes care of this, see the implementation in compat/mingw.c::mingw_offset_1st_component().