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
Two things (April 2019, seven years later):
Don't declare the NTML proxy URL directly. Set HTTP_PROXY
and HTTPS_PROXY
environment variables to and HTTP proxy (not an NTLM one) with, for instance, genotrance/px.
By running px (which redirects to your NTLM proxy), you can refers to a classic HTTP proxy (typically http://localhost:3128, no need for your login/password!), and this will work better.
If the "Resolving deltas" still takes time, make sure to use Git 2.22 (Q2 2019)
On that second point: A progress indicator has been added to the "index-pack
" step, which often makes users wait for completion during "git clone
".
See commit 79e3aa6 (31 Mar 2019) by SZEDER Gábor (szeder).
(Merged by Junio C Hamano -- gitster -- in commit da924b5, 25 Apr 2019)
index-pack
: show progress while checking objectsWhen '
git index-pack
' is run by 'git clone
', itscheck_objects()
function usually doesn't take long enough to be a concern, but I just run into a situation where it took about a minute or so: I inadvertently put some memory pressure on my tiny laptop while cloninglinux.git
, and then there was quite a long silence between the "Resolving deltas
" and "Checking connectivity
" progress bars.Show a progress bar during the loop of
check_objects()
to let the user know that something is still going on.
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.
Not an answer, just contributing symptoms to narrow down the cause of this problem. I have the exact same issue. It just sits there "resolving delta's".
v1.7.10 Win2008 R2 Enterprise Proxy has been configured for HTTP and HTTPs.
I'll get a collegue to login to the server (.gitconfig is part of his roaming profile) and see whether it's the config or the install.
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!
The solution that works for me from comments on this blog http://stas-blogspot.blogspot.ca/2012/12/git-hangs-after-resolving-deltas.html:
Since the pack files have been downloaded correctly all you need to do is to interrupt the process with Ctrl+C, do a git fetch to fetch branch information from the remote repository and checkout the master (or any other) branch again with a git checkout master.
so the solution is just to kill the hanging process and then:
git fetch
git checkout
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:
Ctrl+C
git fetch
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.