Cloning from bare repo fails while using mapped network drive

[undjask]

Hi,

I just encountered a weird error and need somebody else who might be able to reproduce this, because it might be a problem on my side after all. And I don't have anybody else who can try it.

I am working with win 7 64 Bit and Git 1.8.4-preview20130916. I also mapped a drive from a remote (local network) computer to my local machine as G:. I than tried the following list of commands until the error came up. The commands perfectly work if I issue them on a non-mapped local drive. So, it would be very helpful if somebody else could try reproducing the behaviour.

/g/Git/test

$ git init --bare upstream.git

$ git clone upstream.git/ alice

$ cd alice

$ vi file

$ git add .

$ git commit -m "Initial Commit"

[master (root-commit) cb4874f] Initial Commit

 1 file changed, 1 insertion(+)

 create mode 100644 file

$ git push origin master

Counting objects: 3, done.

Writing objects: 100% (3/3), 224 bytes | 0 bytes/s, done.

Total 3 (delta 0), reused 0 (delta 0)

To g:/Git/test/upstream.git/

 * [new branch]      master -> master

$ cd ..

$ git clone upstream.git/ bob

Cloning into 'bob'...

done.

error: internal error: refs/remotes/origin/master is not a valid packed reference!

error: Trying to write ref refs/heads/master with nonexistent object cb4874fbab32f92874bc232befcceb0b10ab7d12

fatal: Cannot update the ref 'HEAD'.

fatal: The remote end hung up unexpectedly

[benoit...@gmail.com]

Hi Undjask,

I am getting a similar issue: creating a submodule within a repository on a mapped drive produces the same error. whereas creating the submodule from the same public repo to a local drive works. But I don't have any issues cloning public repos on a map drive to a folder on a mapped drive.

I have tried giving the source path for the submodule using the server name rather than the mapped drive letter. This did not work.

have you made any progress in finding a solution?

Benoit

[edse...@gmail.com]

I am getting essentially the same errors under a variety of conditions, including ones almost identical to the ones you described. In my case they look like: 

-------------------------------------------------

"C:\Program Files (x86)\Git\bin\git.exe" clone -v --recurse-submodules --progress "Z:/z ejs files/JPA_Tuning_Service repo" "Z:/Software Development/test_repo/Tuning_Service_repo_7"

Cloning into 'Z:/Software Development/test_repo/Tuning_Service_repo_7'...

done.

error: internal error: refs/remotes/origin/S3_HK1_019_BRANCH is not a valid packed reference!

error: internal error: refs/remotes/origin/S3_HK1_020 is not a valid packed reference!

error: internal error: refs/remotes/origin/S3_HK1_020_Source is not a valid packed reference!

error: internal error: refs/remotes/origin/S3_HK1_19 is not a valid packed reference!

error: internal error: refs/remotes/origin/cjones_db is not a valid packed reference!

error: internal error: refs/remotes/origin/master is not a valid packed reference!

error: internal error: refs/tags/20130827_WebServices is not a valid packed reference!

error: internal error: refs/tags/S3_HK1_019RC is not a valid packed reference!

error: internal error: refs/tags/Speedactual_tested_and_deployed is not a valid packed reference!

error: Trying to write ref refs/heads/cjones_db with nonexistent object f964c1a0665911d148ca03f74a6a541311705ad5

fatal: Cannot update the ref 'HEAD'.

fatal: The remote end hung up unexpectedly

Done

-------------------------------------------------

There's a bit of history so please bear with me while I try to include all relevant info. 

System info: Windows 7 64-bit, msys git 1.8.4-preview20130916. I have a remote volume mapped to a local drive as as Z:. 

NOTE: 

- I saw the same errors from a Windows 7 32-bit machine, both when it was running 1.8.3-preview20130601 and after it was upgraded to 1.8.4-preview20130916. (Context and details below.)

- On the 64-bit machine, there were also errors when it was running 1.8.3-preview20130601, but they were different. (I'll include them below.) Once I upgraded it to 1.8.4-preview20130916, its errors matched those on the 32-bit machine. (Context and details below.)

HISTORY:

Some months back I cloned a git repository from my local drive to a folder on the remote volume. This was made as a personal clone, not a bare repo, as it was originally intended to be used for distributing code to other, non-git users. I've been using it actively for months, periodically pushing to it from my local repo. A colleague started using it too, so for a while it served as kind of a "public" repository that we both pushed to and pulled from.  

Today we decided to make a proper public repository and then do some branch maintenance work. Step 1 was to clone the remote repo to a different folder on the same remote volume. That was done from the Win 7 32-bit machine, using git 1.8.3-preview20130601 via the Git Extensions UI. It completed with no errors. 

Step 2 was to make another identical clone of the remote repo to a sibling folder of the clone made in Step 1. This was intended to be a backup, so that if we failed badly in the merge or other maintenance that we had planned, we could start over. This is when the errors started. We were still using the Win 7 32-bit machine and git 1.8.3-preview20130601. We tried multiple times and each time got what appeared to be the same errors. We didn't record the errors at that time, but they were the same as or very similar to the ones shown above. 

At this point I started using the Win 7 64-bit machine and recording the results. (It was still on git 1.8.3-preview20130601 at this time.) The command used and resultant errors were:

-------------------------------------------------

"C:\Program Files (x86)\Git\bin\git.exe" clone -v --recurse-submodules --progress "Z:/z ejs files/JPA_Tuning_Service repo" "Z:/Software Development/Software Repository/Tuning_Service repo 2"

Cloning into 'Z:/Software Development/Software Repository/Tuning_Service repo 2'...

done.

fatal: bad object 9c339b702dcc4ecda55f12f9733a1655e38b0655

fatal: remote did not send all necessary objects

fatal: The remote end hung up unexpectedly

Done

-------------------------------------------------

I made multiple attempts (deleting and/or renaming the target folder each time), but the errors were always the same. I then tried cloning to a local folder and it worked without error the first time. (Keep in mind that I was cloning from the remote volume to the local folder; i.e. this wasn't an "all-local" operation.) 

git fsck (run from the Git Bash window supplied by Git Extensions) reports the following: 

-------------------------------------------------

eds@STEVEM-LAP /z/z ejs files/JPA_Tuning_Service repo (cjones_db)

$ git fsck

Checking object directories: 100% (256/256), done.

Checking objects: 100% (3476/3476), done.

Checking connectivity: 2801, done.

dangling blob dc0644751dc4375a13939036a22cb3f7f964d36b

dangling blob ef26b7cb4150cc7e03b17c17737451f60ee1ba08

dangling blob f3a96e5a67aa73bf42a35c1f9f0aba1e091d529f

-------------------------------------------------

(This output was taken from 1.8.4, but it looked the same before the upgrade. The dangling blobs are obsolete versions of old files.)

My colleague then updated his git to 1.8.4-preview20130916 (on the 32-bit machine) and tried again to clone, but he continued to get the same errors he had seen earlier. I then updated my git to the same version. At this point my errors changed from the "fatal: bad object 9c3..." shown immediately above to the "...is not a valid packed reference!" that my colleague had been seeing all along, and that I included at the top of this post. 

After trying several times, I once again confirmed that I could make a local clone from the remote folder (this time using git 1.8.4-preview20130916). Worked without error the first time. 

It seems clear that something is going wrong when git clones to a remote volume. 

I realize that there are workarounds. I could copy the initial, working clone. I could also try cloning from my original repository (which is local) to the remote volume. These are workarounds that we'll consider for the time being. We can also set up a git server, but first we'll need to find an appropriate machine to run it on, with appropriate backups, etc. (The shared volume is backed up.) But I am hoping to find a real solution, because it's not clear that we'll adopt git for long-term use here and this is exactly the sort of issue that could cause a negative decision to be made. 

Other info: The output of git fsck on the initial, successful clone is almost identical to the output from the remote . The only difference is that it also shows a dangling commit. Using gitk, it's clear that this is months old and I am assuming I abandoned it in the past. It does seem odd that this would appear only in the clone and not in the source of that clone. However I am not an expert on the internals of git so I don't know if this is actually odd or not.

[thinking...@gmail.com]

We were having a similar problem: we could clone a bare repo to a local drive, but were unable to clone to a mapped network drive.

This finally did the trick:

git clone file://<repository location>

Seems you need to include "file://" when cloning to a mapped drive -- at least, that's what worked for us.  Hope it helps!

[cpa...@gmail.com]

That works well. Just a note on the syntax -- if your shared drive is mapped to S:\ and you want to clone the repo to a new folder called project1 in your current working directory, the command would look like this:

git clone file://S:/barerepo.git project1

You must cd to the target folder (or at least the target drive) first, because something like this does not work:

git clone file://S:/barerepo.git file://S:/project1

even if your CWD was already S:\ .

(This pertains to the standard Windows command prompt, not Cygwin or msysgit terminals.)