git clone with NTLM proxy hangs after resolving deltas

Question

I saw here many questions covering git and proxy topics but none of them solves my problem. I am cloning a git repository from Bitbucket. Everything works fine from my home network but hangs at work where we are using proxy with NTLM authentication. See the output of git clone command:

$ git clone https://[email protected]/my_user/my_project.git --verbose
Cloning into 'my_project'...
Password for 'https://[email protected]':
POST git-upload-pack (174 bytes)
remote: Counting objects: 548, done.
remote: Compressing objects: 100% (367/367), done.
remote: Total 548 (delta 216), reused 0 (delta 0)
Receiving objects: 100% (548/548), 5.28 MiB | 533 KiB/s, done.
Resolving deltas: 100% (216/216), done.

git clone command always hangs on "Resolving deltas".

My setup:

• Windows 7 64-bit with msysgit 1.8.0

• proxy configured:

  $git config --global http.proxy http://MY_DOMAIN\\\my_user:my_password@http-proxy:8080
  

---

It seems that the problem is somehow related to git object size because git clone used to work at the very beginning when I had few files only in my repository.

Answer 1

I hit the same issue, with Git 1.7.11. All my attempts to clone from GitHub result in a hung process with no files. I tried the verify-pack trick and many other suggestions in similar questions but nothing worked.

I figured maybe this has been improved or fixed in the latest version of Git, so I upgraded to 1.8.3. Bingo, now it works, I can clone!

Answer 2

Sorry, my english is very bad. Hope you can understand.

I got the same problem here. I can't find and fix the problem but i finally able to checkout. When git clone hangs on "Resolving deltas", kill the git process. So, you have folder my_project, and file .git\objects\pack\pack-<sha1>.pack. Now, we need to find the revision number. Type this command below:

git verify-pack -v .git\objects\pack\pack-<sha1>.pack | grep "commit" | more

and the output is something like this:

98c9f779992fc9a52372e0a1a76647e5d9ca5e01 commit 340 227 12
b6435d98f7b62ce69c59ce582beddf547f26d8a2 commit 305 208 239
a2a39a0c707b2919c87b194dca9a0dea307ce069 commit 239 159 447
...
4803e013b30dc9d31e4a8dba7e1a2d65e6f61422 commit 243 167 6768
-- More  --    

The 98c9f779992fc9a52372e0a1a76647e5d9ca5e01 at the top is HEAD revision, so you can checkout to this point:

git checkout -b master 98c9f779992fc9a52372e0a1a76647e5d9ca5e01

Done.

Answer 3

I have the same issue and although I can't pinpoint the cause I have what I reckon is a slightly better workaround than using verify-pack and checkout the last commit as explained by cakyus.

The problem with checking out the last commit as the master branch is that you can't guarantee that the commit belongs to that branch in particular, so what I did was:

• Interrupt the git process that hung on resolving deltas with Ctrl+C
• Fetch branch information with git fetch
• Checkout the master branch (or any other branch) with git checkout master

This made git set up my branch master to track remote branch master and unpack the files correctly while also preserving branch information.