git clone con il proxy NTLM si blocca dopo la risoluzione dei delta

Question

Ho visto qui molte domande riguardanti argomenti git e proxy ma nessuno di loro risolve il mio problema. Sto clonando un repository git da Bitbucket. Tutto funziona alla perfezione dalla mia rete domestica ma si blocca al lavoro dove stiamo usando il proxy con autenticazione NTLM. Vedere l'output del comando git clone: ​​

$ git clone https://my_user@bitbucket.org/my_user/my_project.git --verbose 
Cloning into 'my_project'... 
Password for 'https://my_user@bitbucket.org': 
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. 

Il comando git clone si blocca sempre su "Risolvi delta".

La mia configurazione:

• Windows 7 64-bit con msysgit 1.8.0

• proxy configurato:

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

---

Sembra che il problema è in qualche modo relativo alla dimensione dell'oggetto git perché il clone git utilizzato per funzionare proprio all'inizio quando ho d pochi file solo nel mio repository.

Answer 1

Ho riscontrato lo stesso problema con Git 1.7.11. Tutti i miei tentativi di clonare da GitHub portano a un processo bloccato senza file. Ho provato il trucco verify-pack e molti altri suggerimenti in domande simili ma non ha funzionato.

Ho pensato che forse questo è stato migliorato o risolto nell'ultima versione di Git, quindi ho aggiornato a 1.8.3. Bingo, ora funziona, posso clonare!

Answer 2

Non una risposta, solo un contributo ai sintomi per restringere la causa di questo problema. Ho lo stesso identico problema. Si siede lì "risolvendo le delta".

v1.7.10 Win2008 R2 Enterprise Il proxy è stato configurato per HTTP e HTTP.

Vado a un collega per accedere al server (.gitconfig fa parte del suo profilo di roaming) e vedere se è la configurazione o l'installazione.

Answer 3

Scusa, il mio inglese è pessimo. Spero tu possa capire.

Ho avuto lo stesso problema qui. Non riesco a trovare e risolvere il problema ma finalmente riesco a fare il checkout. Quando git clone si blocca su "Resolving deltas", elimina il processo git. Quindi, hai la cartella my_project e il file .git\objects\pack\pack-<sha1>.pack. Ora, dobbiamo trovare il numero di revisione. Digitare il seguente comando:

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

e l'uscita è qualcosa di simile:

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

Il 98c9f779992fc9a52372e0a1a76647e5d9ca5e01 in alto è la testa di revisione, in modo da poter checkout a questo punto:

git checkout -b master 98c9f779992fc9a52372e0a1a76647e5d9ca5e01 

Fatto.

Answer 4

Ho lo stesso problema e anche se non riesco a individuare la causa ho quello che considero una soluzione leggermente migliore rispetto all'utilizzo di verify-pack e checkout l'ultimo commit come spiegato da cakyus.

Il problema con il check-out l'ultimo commit come ramo principale è che non si può garantire che il commettere appartiene a quel ramo in particolare, così quello che ho fatto è stato:

• interrompere il processo di git che appeso a delta risolvendo con Ctrl+C
• recuperare informazioni ramo con git fetch
• Checkout ramo principale (o qualsiasi altra filiale) con git checkout master

Questo ha reso git il mio master di ramo per tracciare il master di ramo remoto e decomprimere correttamente i file preservando anche le informazioni di ramo.

Answer 5

La soluzione che funziona per me dai commenti su questo blog http://stas-blogspot.blogspot.ca/2012/12/git-hangs-after-resolving-deltas.html:

Dal momento che i file del pacchetto sono stati scaricati correttamente tutto quello che dovete fare è quello di interrompere il processo con Ctrl + C, fare un git fetch recuperare le informazioni sulle diramazioni dal repository remoto e controllare di nuovo il ramo master (o qualsiasi altro) con un master di checkout git.

quindi la soluzione è solo per uccidere il processo di impiccagione e poi:

git fetch 
git checkout