¿Por qué colgaría git-upload-pack (durante la copy de git)?

He leído varias otras preguntas de 'git cuelga en clon', pero ninguna coincide con mi entorno y detalles. Estoy usando git construido bajo cygwin (msys git no es una opción) para clonar un repository desde un host Linux a través de SSH.

git clone user@host:repo 

He probado contra el mismo host en otras plataforms, y funciona bien, pero en esta máquina de Windows, el clon se cuelga indefinidamente. Configuro GIT_TRACE=1 y parece que el problema es con este command:

 'ssh' 'user@host' 'git-upload-pack '\''repo'\''' 

Mis keys SSH están configuradas correctamente: ssh user@host funciona bien. Cuando ejecuto el command, obtengo un montón de resultados que terminan así:

 ... 003dbbd3db63763922ad75bbeefa3811dce001576851 refs/tags/start 0000 

Luego se cuelga por más de 20 minutos, que es el time más largo que he esperado antes de matarlo.

El server tiene Git 1.7.11.7 con OpenSSH 5.9p1, mientras que el cliente tiene Git 1.7.9 con OpenSSH 6.1p1.

Se supone que es el final de la salida de git-upload-pack? ¿Es esto un error en Git o mi configuration?

El próximo git1.8.5 (Q4 2013) documentará más el protocolo http inteligente.
Ver commit 4c6fffe2ae3642fa4576c704e2eb443de1d0f8a1 por Shawn O. Pearce .

Con esa documentation detallada, la idea sería supervisar las requestes web realizadas entre su cliente de git y el server, y ver si se ajusta a lo que se documenta a continuación.

Eso podría ayudar a identificar dónde se cuelga el service.


El file Documentation/technical/http-protocol.txt insiste en:

  • el " Servicio inteligente git-upload-pack "

    • Los clientes DEBEN realizar primero ref discovery 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 
    • Los clientes NO DEBEN reutilizar o revalidar una respuesta en caching.

    • Los serveres DEBEN include suficientes encabezados de control de caching para evitar el almacenamiento en caching de la respuesta.
    • Los serveres DEBERÍAN soportar todas las capacidades definidas aquí.
    • Los clientes DEBEN enviar al less un command 'want' en el cuerpo de la request.
    • Los clientes NO DEBEN hacer reference a una identificación en un command 'querer' que no apareció en la respuesta obtenida a través del descubrimiento de ref a less que el server anuncie la capacidad "allow-tip-sha1-in-want".
  • El algorithm de "negociación"

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

Un PuTTy obsoleto también puede causar esto. Su sistema podría estar usando plink.exe como GIT_SSH .

Puede instalar la última compilation de desarrollo en http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html para asegurarse de que este no sea el problema.

Nos hemos enfrentado a un problema similar, y lo hemos atribuido a lo siguiente: Nuestro git repo tiene MUCHOS files binarys registrados (versiones múltiples, en los últimos 1.5 años de este proyecto). Entonces, asumimos que esta era la causa.

Para apoyar esta teoría, tenemos otras bases de códigos que son más recientes (y por lo tanto no tienen tantos files binarys y sus versiones), que no exhiben este comportamiento.

Nuestra configuration: configuration de Git en Linux, VPN de sitio a sitio entre Londres e India a través de una línea T1.

Estaba teniendo el mismo problema después de agregar un poco de jazz como este a mi configuration de ssh para establecer títulos de window en tmux:

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

deshacerse de eso solucionó mi problema.

Esto funcionó para mí, en caso de que ayude a otra persona.

Comtesting tu URL remota de git. Podría bloquearse con git-upload-pack en un rastreo si utiliza el tipo de url incorrecto. cambie la URL de git@github.com: a https://github.com/ en su control remoto.