mac keygen generate create windows git ssh

windows - keygen - github use ssh key



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

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 repositorio desde un host Linux a través de SSH.

git clone user@host:repo

He probado contra el mismo host en otras plataformas, 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 comando:

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

Mis claves SSH están configuradas correctamente: ssh user@host funciona bien. Cuando ejecuto el comando, 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 tiempo más largo que he esperado antes de matarlo.

El servidor 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 configuración?

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

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

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

El archivo 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 caché.

    • Los servidores DEBEN incluir suficientes encabezados de control de caché para evitar el almacenamiento en caché de la respuesta.
    • Los servidores DEBERÍAN soportar todas las capacidades definidas aquí.
    • Los clientes DEBEN enviar al menos un comando ''want'' en el cuerpo de la solicitud.
    • Los clientes NO DEBEN hacer referencia a una identificación en un comando ''querer'' que no apareció en la respuesta obtenida a través del descubrimiento de ref a menos que el servidor anuncie la capacidad "allow-tip-sha1-in-want".

  • El algoritmo de "negociación"

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

Estaba teniendo el mismo problema después de agregar un poco de jazz como este a mi configuración de ssh para establecer títulos de ventana 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 alguien más.

Comprueba 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 [email protected]: a https://github.com/ en su control remoto.

Nos hemos enfrentado a un problema similar, y lo hemos atribuido a lo siguiente: Nuestro git repo tiene MUCHOS archivos binarios 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 archivos binarios y sus versiones), que no exhiben este comportamiento.

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