2013-06-12 15 views
21

Ho letto diverse altre domande "git hangs on clone", ma nessuna corrisponde al mio ambiente e ai miei dettagli. Sto usando git costruito sotto cygwin (msys git non è un'opzione) per clonare un repository da un host Linux su SSH.Perché git-upload-pack (durante il clone git) si blocca?

git clone [email protected]:repo 

ho testato contro lo stesso host su altre piattaforme, e funziona bene, ma su questa macchina di Windows il clone si blocca a tempo indeterminato. Ho impostato GIT_TRACE=1 e sembra che il problema è con questo comando:

'ssh' '[email protected]' 'git-upload-pack '\''repo'\''' 

mie chiavi SSH siano impostati correttamente: ssh [email protected] funziona bene. Quando eseguo l'ordine, ho un po 'di output che si conclude in questo modo:

... 
003dbbd3db63763922ad75bbeefa3811dce001576851 refs/tags/start 
0000 

Poi si blocca per 20 minuti, che è il più lungo ho aspettato prima di ucciderlo.

Il server ha Git 1.7.11.7 con OpenSSH 5.9p1, mentre il client ha Git 1.7.9 con OpenSSH 6.1p1.

Si suppone che sia la fine dell'uscita git-upload-pack? Si tratta di un bug in Git o nella mia configurazione?

+0

hai provato a copiare un clone (da linux/mac) sul pc di Windows e lo hai "usato"? forse alcuni problemi di git con Windows (insensibilità alle maiuscole/minuscole, codifica dei caratteri, ...) è la ragione, e questo potrebbe aiutare a rintracciarlo. – mnagel

+1

Questo è previsto da 'git-upload-pack'. Ti sta aspettando (beh, il tuo cliente git) per fare qualche trattativa dove richiedi qualcosa, dicendogli cosa vuoi * e cosa hai * *. Non puoi davvero usare nessun altro client git per la risoluzione dei problemi? –

+0

@EdwardThomson Non ho più accesso a quell'ambiente, ma no, non ho avuto la possibilità di utilizzare nessun altro client git. Sia il server che il client sono stati compilati dall'origine, quindi non ci dovrebbero essere state differenze nel comportamento se non come introdotto nel codice e nelle dipendenze specifici della piattaforma. – DNS

risposta

0

Abbiamo affrontato un problema simile - e lo abbiamo attribuito al seguente: Il nostro repository git ha un sacco di file binari registrati (più versioni, negli ultimi 1,5 anni di questo progetto). Quindi, abbiamo pensato che questa fosse la causa.

Per supportare questa teoria, abbiamo altre basi di codice che sono più recenti (e quindi non hanno così tanti file binari e le loro versioni) - che non mostrano questo comportamento.

La nostra configurazione: configurazione Git su linux, VPN site-to-site tra Londra e l'India su una linea T1.

+0

Il mio repository aveva un sacco di oggetti binari, ma nel mio caso il clone era su un collegamento locale gigabit. La clonazione su altre piattaforme (testata su Mac, Linux, Solaris) dello stesso repository ha richiesto circa pochi minuti. Quindi, a meno che git su Windows non sia più lento di ordini di grandezza per qualche ragione, che non è la mia esperienza di utilizzo altrove, probabilmente il problema non è legato alla dimensione o ai contenuti del repository. – DNS

2

Il prossimo git1.8.5 (4 ° trimestre 2013) documenterà di più il protocollo http.
Vedere commit 4c6fffe2ae3642fa4576c704e2eb443de1d0f8a1 entro il Shawn O. Pearce.

Con questa documentazione dettagliata, l'idea sarebbe di monitorare le richieste Web eseguite tra il client git e il server e verificare se sono conformi a quanto riportato di seguito.

Ciò potrebbe aiutare a individuare dove il servizio "si blocca".


Il file Documentation/technical/http-protocol.txt insiste su:

  • la scoperta "Smart Service git-upload-pack"

    • Clienti DEVE prima eseguire ref con '$GIT_URL/info/refs?service=git-upload-pack'.

      C: POST $GIT_URL/git-upload-pack HTTP/1.0 
      S: 200 OK 
      S: Content-Type: application/x-git-upload-pack-result 
      S: Cache-Control: no-cache 
      S: 
      S: ....ACK %s, continue 
      S: ....NAK 
      
    • Clienti NON DEVE riutilizzare o rinnovare un reponse cache.

    • I server DEVONO includere un numero sufficiente di intestazioni Cache-Control per impedire la memorizzazione nella cache della risposta.
    • I server DOVREBBE supportare tutte le funzionalità definite qui.
    • I client DEVONO inviare almeno un comando 'desidera' nel corpo della richiesta.
    • I client NON DEVONO fare riferimento a un ID in un comando 'want' che non è stato visualizzato nella risposta ottenuta tramite la ricerca ref, a meno che il server non pubblicizzi la funzionalità "allow-tip-sha1-in-want".
  • Il "negociation" algorithm

    (c) Send one $GIT_URL/git-upload-pack request: 
    C: 0032want <WANT #1>............................... 
    
0

ho avuto questo stesso problema dopo ho aggiunto un po 'di jazz come questo per il mio ssh config al fine di impostare titoli di finestra in tmux:

Host * 
PermitLocalCommand yes 
LocalCommand if [[ $TERM == screen* ]]; then printf "\033k%h\033\\"; fi 

sbarazzarsi di quello fissato il mio git.

0

Questo ha funzionato per me, nel caso in cui aiuti qualcun altro.

Controlla l'URL del tuo git remoto. Potrebbe bloccarsi con git-upload-pack su una traccia se si utilizza il tipo di URL errato. cambia l'url da [email protected]: a https://github.com/ sul tuo telecomando.