¿Cómo puedo tener alguna información de depuración con respecto a git / git-shell?

Tuve un problema, que user1podía clonar un repositorio sin problemas, mientras que user2podía clonar solo uno vacío. Me había puesto GIT_TRACE=1, pero no me dijeron nada útil.

Finalmente, después de una larga prueba y error, resultó que era un problema de permiso en un archivo. Un mensaje de error apropiado podría provocar un cortocircuito en este problema.

Para obtener resultados aún más detallados, utilice lo siguiente:

GIT_CURL_VERBOSE=1 GIT_TRACE=1 git pull origin master

Depuración

Git tiene un conjunto bastante completo de trazas incrustadas que puede usar para depurar sus problemas de git.

Para activarlos, puede definir las siguientes variables:

• GIT_TRACE para rastros generales,
• GIT_TRACE_PACK_ACCESS para rastrear el acceso a los archivos de paquete,
• GIT_TRACE_PACKET para el rastreo a nivel de paquete para operaciones de red,
• GIT_TRACE_PERFORMANCE para registrar los datos de rendimiento,
• GIT_TRACE_SETUP para obtener información sobre cómo descubrir el repositorio y el entorno con el que está interactuando,
• GIT_MERGE_VERBOSITY para depurar la estrategia de fusión recursiva (valores: 0-5),
• GIT_CURL_VERBOSEpara registrar todos los mensajes curl (equivalente a curl -v),
• GIT_TRACE_SHALLOW para depurar la recuperación / clonación de repositorios poco profundos.

Los valores posibles pueden incluir:

• true, 1O 2escribir en stderr,
• una ruta absoluta que comienza /por rastrear la salida hasta el archivo especificado.

Para más detalles, ver: Git Internals - Variables de entorno

SSH

Para problemas de SSH, pruebe los siguientes comandos:

echo 'ssh -vvv "$*"' > ssh && chmod +x ssh
GIT_SSH="$PWD/ssh" git pull origin master

o use sshpara validar sus credenciales, por ejemplo

ssh -vvvT [email protected]

o sobre el puerto HTTPS:

ssh -vvvT -p 443 [email protected]

^{Nota: Reduzca el número de -vpara reducir el nivel de verbosidad.}

Ejemplos

$ GIT_TRACE=1 git status
20:11:39.565701 git.c:350               trace: built-in: git 'status'

$ GIT_TRACE_PERFORMANCE=$PWD/gc.log git gc
Counting objects: 143760, done.
...
$ head gc.log 
20:12:37.214410 trace.c:420             performance: 0.090286000 s: git command: 'git' 'pack-refs' '--all' '--prune'
20:12:37.378101 trace.c:420             performance: 0.156971000 s: git command: 'git' 'reflog' 'expire' '--all'
...

$ GIT_TRACE_PACKET=true git pull origin master
20:16:53.062183 pkt-line.c:80           packet:        fetch< 93eb028c6b2f8b1d694d1173a4ddf32b48e371ce HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed symref=HEAD:refs/heads/master agent=git/2:2.6.5~update-ref-initial-update-1494-g76b680d
...

prueba este:

GIT_TRACE=1 git pull origin master

Si está sobre SSH, puede usar lo siguiente:

Para un nivel de depuración más alto para el tipo -vv o -vvv para el nivel de depuración 2 y 3 respectivamente:

# Debug level 1
GIT_SSH_COMMAND="ssh -v" git clone <repositoryurl>

# Debug level 2
GIT_SSH_COMMAND="ssh -vv" git clone <repositoryurl>

# Debug level 3
GIT_SSH_COMMAND="ssh -vvv" git clone <repositoryurl>

Esto es principalmente útil para manejar problemas de clave pública y privada con el servidor. Puede usar este comando para cualquier comando git, no solo 'git clone'.

Git 2.9.x / 2,10 (Q3 2016) añade otra opción de depuración: GIT_TRACE_CURL.

Ver commit 73e57aa , commit 74c682d (23 de mayo de 2016) por Elia Pinto ( devzero2000) .
Ayudado por: Torsten Bögershausen ( tboegi) , Ramsay Jones, Junio ​​C Hamano ( gitster) , Eric Sunshine ( sunshineco) y Jeff King ( peff) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 2f84df2 , 06 jul 2016)}

http.c: implementar la GIT_TRACE_CURLvariable de entorno

Implemente la GIT_TRACE_CURLvariable de entorno para permitir un mayor grado de detalle GIT_CURL_VERBOSE, en particular, el encabezado de transporte completo y toda la carga útil de datos intercambiada.
Podría ser útil si una situación particular pudiera requerir un análisis de depuración más completo.

La documentación indicará:

GIT_TRACE_CURL

Permite un volcado de seguimiento completo de rizos de todos los datos entrantes y salientes, incluida la información descriptiva, del protocolo de transporte git.
Esto es similar a hacerlo curl --trace-asciien la línea de comando.

Esta opción anula la configuración de la GIT_CURL_VERBOSEvariable de entorno.

Puede ver esa nueva opción utilizada en esta respuesta , pero también en las pruebas Git 2.11 (Q4 2016):

Ver commit 14e2411 , commit 81590bf , commit 4527aa1 , commit 4eee6c6 (07 de septiembre de 2016) por Elia Pinto ( devzero2000) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 930b67e , 12 sep 2016)}

Use la nueva GIT_TRACE_CURLvariable de entorno en lugar de la obsoleta GIT_CURL_VERBOSE .

GIT_TRACE_CURL=true git clone --quiet $HTTPD_URL/smart/repo.git

Git 2.22 (Q2 2019) presenta trace2con commit ee4512e de Jeff Hostetler :

trace2: crear una nueva instalación de rastreo combinada

Cree una nueva instalación de rastreo unificada para git.
La intención final es reemplazar el actual trace_printf*y las trace_performance*rutinas con un conjunto unificado de git_trace2*rutinas.

Además de la API de estilo printf habitual, trace2proporciona verbos de eventos de nivel superior con campos fijos que permiten escribir datos estructurados.
Esto facilita el procesamiento posterior y el análisis para herramientas externas.

Trace2 define 3 objetivos de salida.
Estos se configuran utilizando las variables de entorno " GIT_TR2", " GIT_TR2_PERF" y " GIT_TR2_EVENT".
Estos pueden establecerse en "1" o en una ruta absoluta (al igual que la actual GIT_TRACE).

Nota: con respecto al nombre de la variable de entorno, use siempre GIT_TRACExxx, no GIT_TRxxx.
Entonces GIT_TRACE2, en realidad , GIT_TRACE2_PERFo GIT_TRACE2_EVENT.
Vea el cambio de nombre de Git 2.22 mencionado más adelante.

Lo que sigue es el trabajo inicial en esta nueva característica de rastreo, con los antiguos nombres de variables de entorno:

• GIT_TR2está destinado a ser un reemplazo GIT_TRACEy registra datos de resumen de comandos.

• GIT_TR2_PERFestá destinado a reemplazar a GIT_TRACE_PERFORMANCE.
  Extiende la salida con columnas para el proceso de comando, subproceso, repos, tiempos transcurridos absolutos y relativos. Informa eventos para inicio / detención de procesos secundarios, inicio / detención de subprocesos y anidamiento de funciones por subproceso.

• GIT_TR2_EVENTEs un nuevo formato estructurado. Escribe datos de eventos como una serie de registros JSON.

Las llamadas a las funciones de trace2 se registran en cualquiera de los 3 destinos de salida habilitados sin la necesidad de llamar a rutinas trace_printf*o diferentes trace_performance*.

Ver commit a4d3a28 (21 mar 2019) por Josh Steadmon ( steadmon) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 1b40314 , 08 de mayo de 2019)}

trace2: escribir en los destinos del directorio

Cuando el valor de una variable de entorno trace2 es una ruta absoluta que hace referencia a un directorio existente, escriba la salida en los archivos (uno por proceso) debajo del directorio dado.
Los archivos se nombrarán de acuerdo con el componente final del SID trace2, seguido de un contador para evitar posibles colisiones.

Esto hace que sea más conveniente recopilar rastreos para cada invocación de git configurando incondicionalmente el entorno relevante trace2a un nombre de directorio constante.

Ver también commit f672dee (29 abr 2019) y commit 81567ca , commit 08881b9 , commit bad229a , commit 26c6f25 , commit bce9db6 , commit 800a7f9 , commit a7bc01e , commit 39f4317 , commit a089724 , commit 1703751 (15 abr 2019) por Jeff Hostetler ( jeffhostetler) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 5b2d1c0 , 13 de mayo de 2019)}

La nueva documentación ahora incluye ajustes de configuración que solo se leen del sistema y archivos de configuración globales (lo que significa que -cno se respetan los archivos de configuración del repositorio local y worktree y los argumentos de la línea de comandos).

Ejemplo :

$ git config --global trace2.normalTarget ~/log.normal
$ git version
git version 2.20.1.155.g426c96fcdb

rendimientos

$ cat ~/log.normal
12:28:42.620009 common-main.c:38                  version 2.20.1.155.g426c96fcdb
12:28:42.620989 common-main.c:39                  start git version
12:28:42.621101 git.c:432                         cmd_name version (version)
12:28:42.621215 git.c:662                         exit elapsed:0.001227 code:0
12:28:42.621250 trace2/tr2_tgt_normal.c:124 atexit elapsed:0.001265 code:0

Y para medir el rendimiento :

$ git config --global trace2.perfTarget ~/log.perf
$ git version
git version 2.20.1.155.g426c96fcdb

rendimientos

$ cat ~/log.perf
12:28:42.620675 common-main.c:38                  | d0 | main                     | version      |     |           |           |            | 2.20.1.155.g426c96fcdb
12:28:42.621001 common-main.c:39                  | d0 | main                     | start        |     |  0.001173 |           |            | git version
12:28:42.621111 git.c:432                         | d0 | main                     | cmd_name     |     |           |           |            | version (version)
12:28:42.621225 git.c:662                         | d0 | main                     | exit         |     |  0.001227 |           |            | code:0
12:28:42.621259 trace2/tr2_tgt_perf.c:211         | d0 | main                     | atexit       |     |  0.001265 |           |            | code:0

Como se documenta en Git 2.23 (Q3 2019), la variable de entorno a usar es GIT_TRACE2.

Ver commit 6114a40 (26 de junio de 2019) por Carlo Marcelo Arenas Belón ( carenas) .
Ver commit 3efa1c6 (12 de junio de 2019) por Ævar Arnfjörð Bjarmason ( avar) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit e9eaaa4 , 09 jul 2019)}

Eso sigue el trabajo realizado en Git 2.22: commit 4e0d3aa , commit e4b75d6 (19 de mayo de 2019) por SZEDER Gábor ( szeder) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 463dca6 , 30 de mayo de 2019)}

trace2: cambiar el nombre de las variables de entorno a GIT_TRACE2 *

Para una variable de entorno que los usuarios deben establecer, los GIT_TR2*entornos son demasiado poco claros, inconsistentes y feos.

La mayoría de las establecidas GIT_*las variables de entorno no utilizan abreviaturas, y en el caso de los pocos que hacer ( GIT_DIR, GIT_COMMON_DIR, GIT_DIFF_OPTS) es bastante obvio lo que las abreviaturas ( DIRy OPTS) representan.
¿Pero qué significa TR? Seguimiento, tradicional, tráiler, transacción, transferencia, transformación, transición, traducción, trasplante, transporte, recorrido, árbol, disparador, truncamiento, confianza o ...

Se supone que la instalación trace2, como sugiere el sufijo '2' en su nombre, eventualmente reemplazará a la instalación de rastreo original de Git.
Es razonable esperar que las variables de entorno correspondientes siguen el juego, y después de la original de GIT_TRACElas variables se les llama GIT_TRACE2; no hay tal cosa es ' GIT_TR'.

Todas las variables de configuración específicas de trace2 están, muy sensiblemente, en la trace2sección ' ', no en ' tr2'.

OTOH, no ganamos nada omitiendo los últimos tres caracteres de "rastreo" de los nombres de estas variables de entorno .

Así que cambiemos el nombre de todas GIT_TR2*las variables de entorno a GIT_TRACE2*, antes de que lleguen a una versión estable.

Git 2.24 (Q3 2019) mejora la inicialización del repositorio de Git.

Ver commit 22932d9 , commit 5732f2b , commit 58ebccb (06 de agosto de 2019) por Jeff King ( peff) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit b4a1eec , 09 sep 2019)}

common-main: retraso en la inicialización de trace2

Inicializamos el trace2sistema en la función main () común para que todos los programas (incluso los que no están integrados) permitan el rastreo.

Pero el trace2inicio es relativamente pesado, ya que tenemos que leer la configuración en el disco para decidir si rastrear.
Esto puede causar interacciones inesperadas con otra inicialización común-principal. Por ejemplo, terminaremos en el código de configuración antes de llamar initialize_the_repository(), y el invariante habitual que the_repositorynunca es NULL no se mantendrá.

Empujemos la trace2inicialización más abajo en common-main, justo antes de ejecutar cmd_main().

Git 2.24 (Q4 2019) también se asegura de que la salida del trace2subsistema esté formateada ahora con más precisión.

Ver commit 742ed63 , commit e344305 , commit c2b890a (09 de agosto de 2019), commit ad43e37 , commit 04f10d3 , commit da4589c (08 de agosto de 2019) y commit 371df1b (31 de julio de 2019) por Jeff Hostetler ( jeffhostetler) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 93fc876 , 30 sep 2019)}

Y, todavía Git 2.24

Ver commit 87db61a , commit 83e57b0 (04 Oct 2019), y commit 2254101 , commit 3d4548e (03 Oct 2019) por Josh Steadmon ( steadmon) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit d0ce4d9 , 15 oct 2019)}

trace2: descarta nuevos rastros si el directorio de destino tiene demasiados archivos

^{Firmado por: Josh Steadmon}

trace2puede escribir archivos en un directorio de destino.
Con un uso intensivo, este directorio puede llenarse con archivos, lo que causa dificultades para los sistemas de procesamiento de rastreo.

Este parche agrega una opción de configuración ( trace2.maxFiles) para establecer un número máximo de archivos que trace2se escribirán en un directorio de destino.

El siguiente comportamiento se habilita cuando maxFilesse establece en un entero positivo:

• Cuando trace2escribiría un archivo en un directorio de destino, primero verifique si las trazas deben descartarse o no. Los rastros deben descartarse si:

  • hay un archivo centinela que declara que hay demasiados archivos
  • O, el número de archivos excede trace2.maxFiles.
    En el último caso, creamos un archivo centinela llamado git-trace2-discardpara acelerar futuras comprobaciones.

La suposición es que un sistema de procesamiento de trazas separado se ocupa de las trazas generadas; una vez que procesa y elimina el archivo centinela, debería ser seguro generar nuevos archivos de rastreo nuevamente.

El valor predeterminado para trace2.maxFileses cero, lo que deshabilita la verificación del recuento de archivos.

La configuración también puede ser reemplazado con una nueva variable de entorno: GIT_TRACE2_MAX_FILES.

Y Git 2.24 (Q4 2019) enseña trace2 sobre git pushetapas.

Ver commit 25e4b80 , commit 5fc3118 (02 oct 2019) por Josh Steadmon ( steadmon) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 3b9ec27 , 15 oct 2019)}

push: agregar instrumentación trace2

^{Firmado por: Josh Steadmon}

Agregue regiones trace2 en transport.cy builtin/push.cpara realizar un mejor seguimiento del tiempo empleado en varias fases de empuje:

• Listado de referencias
• Comprobación de submódulos
• Submódulos de empuje
• Empujando refs

Con Git 2.25 (Q1 2020), parte del Documentation/technicalse mueve a los *.harchivos de encabezado .

Ver cometer 6c51cb5 , cometen d95a77d , comprometerse bbcfa30 , comprometerse f1ecbe0 , comprometerse 4c4066d , comprometerse 7db0305 , comprometerse f3b9055 , comprometerse 971b1f2 , comprometerse 13aa9c8 , comprometerse c0be43f , comprometerse 19ef3dd , comprometerse 301d595 , comprometerse 3a1b341 , comprometerse 126c1cc , comprometerse d27eb35 , comprometerse 405c6b1 , cometen d3d7172 , commit 3f1480b , commit 266f03e , commit 13c4d7e(17 nov 2019) por Heba Waly ( HebaWaly) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 26c816a , 16 dic 2019)}

trace2: mover el documento a trace2.h

^{Firmado por: Heba Waly}

Mueva la documentación de funciones de Documentation/technical/api-trace2.txta, trace2.hya que es más fácil para los desarrolladores encontrar la información de uso junto al código en lugar de buscarla en otro archivo doc.

Solo se elimina la sección de documentación de funciones, Documentation/technical/api-trace2.txtya que el archivo está lleno de detalles que parecían más apropiados para estar en un archivo doc por separado, con un enlace al archivo doc agregado en trace2.h. También se elimina el documento de funciones para evitar tener información redundante que será difícil de sincronizar con la documentación en el archivo de encabezado.

(aunque esa reorganización tuvo un efecto secundario en otro comando, explicado y corregido con Git 2.25.2 (marzo de 2020) en commit cc4f2eb (14 de febrero de 2020) por Jeff King ( peff) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 1235384 , 17 de febrero de 2020)} )

Con Git 2.27 (Q2 2020): Mejora de Trace2 para permitir el registro de las variables de entorno .

Ver commit 3d3adaa (20 de marzo de 2020) por Josh Steadmon ( steadmon) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 810dc64 , 22 de abril de 2020)}

trace2: enseñar a Git a registrar variables de entorno

^{Firmado por: Josh Steadmon
: Jeff Hostetler}

A través de trace2, Git ya puede registrar parámetros de configuración interesantes (consulte el trace2_cmd_list_config() función). Sin embargo, esto puede otorgar una imagen incompleta porque muchos parámetros de configuración también permiten anulaciones a través de variables de entorno.

Para permitir registros más completos, agregamos una nueva trace2_cmd_list_env_vars()función y una implementación de soporte, modelada a partir de la implementación de registro de parámetros de configuración preexistente.

Con Git 2.27 (Q2 2020), enseñe las rutas de código que muestran el medidor de progreso para usar también start_progress()las stop_progress()llamadas y como un " region" para rastrear.

Ver commit 98a1364 (12 de mayo de 2020) por Emily Shaffer ( nasamuffin) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit d98abce , 14 de mayo de 2020)}

trace2: registrar el tiempo de progreso y el rendimiento

^{Firmado por: Emily Shaffer}

En lugar de enseñar solo una operación, como ' git fetch', cómo escribir el rendimiento en las trazas, podemos aprender sobre una amplia gama de operaciones del usuario que pueden parecer lentas al agregar herramientas a la propia biblioteca de progreso .

Es probable que las operaciones que muestran el progreso sean lentas y el tipo de cosas que queremos monitorear para el rendimiento de todos modos.

Al mostrar los recuentos de objetos y el tamaño de la transferencia de datos, deberíamos poder realizar algunas mediciones derivadas para garantizar que las operaciones se escalen de la manera que esperamos.

Y:

Con Git 2.27 (Q2 2020), corrección de último minuto para nuestro cambio reciente para permitir el uso de API de progreso como una región rastreable.

Ver commit 3af029c (15 de mayo de 2020) por Derrick Stolee ( derrickstolee) .
^{(Fusión por Junio ​​C Hamano - gitster- en commit 85d6e28 , 20 de mayo de 2020)}

progress: llame trace2_region_leave()solo después de llamar_enter()

^{Firmado por: Derrick Stolee}

Un usuario de API de progreso llama start_progress()condicionalmente y depende de las funciones display_progress()y stop_progress()para convertirse en no operativo cuando start_progress()no se ha llamado.

Cuando agregamos una llamada a trace2_region_enter()to start_progress(), las llamadas a otras llamadas de API trace2 desde las funciones de API de progreso deben asegurarse de que estas llamadas trace2 se omitan cuandostart_progress() no se ha llamado en la estructura de progreso.

Específicamente, no llame trace2_region_leave()desde stop_progress()cuando no hemos llamado start_progress(), lo que habría llamado la coincidencia trace2_region_enter().

¿Has intentado agregar el -voperador verbose ( ) cuando clonas?

git clone -v git://git.kernel.org/pub/scm/.../linux-2.6 my2.6

Para versiones anteriores de git (1.8 y anteriores)

No pude encontrar una manera adecuada de habilitar la depuración SSH en versiones anteriores de git y ssh. Busqué variables de entorno usandoltrace -e getenv ... y no pude encontrar ninguna combinación de variables GIT_TRACE o SSH_DEBUG que funcionara.

En cambio, aquí hay una receta para inyectar temporalmente 'ssh -v' en la secuencia git-> ssh:

$ echo '/usr/bin/ssh -v ${@}' >/tmp/ssh
$ chmod +x /tmp/ssh
$ PATH=/tmp:${PATH} git clone ...
$ rm -f /tmp/ssh

Aquí está la salida de git versión 1.8.3 con la versión ssh OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 de febrero de 2013 clonando un repositorio de github:

$ (echo '/usr/bin/ssh -v ${@}' >/tmp/ssh; chmod +x /tmp/ssh; PATH=/tmp:${PATH} \
   GIT_TRACE=1 git clone https://github.com/qneill/cliff.git; \
   rm -f /tmp/ssh) 2>&1 | tee log
trace: built-in: git 'clone' 'https://github.com/qneill/cliff.git'
trace: run_command: 'git-remote-https' 'origin' 'https://github.com/qneill/cliff.git'
Cloning into 'cliff'...
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /home/q.neill/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to github.com ...
...
Transferred: sent 4120, received 724232 bytes, in 0.2 seconds
Bytes per second: sent 21590.6, received 3795287.2
debug1: Exit status 0
trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all'
trace: exec: 'git' 'rev-list' '--objects' '--stdin' '--not' '--all'
trace: built-in: git 'rev-list' '--objects' '--stdin' '--not' '--all'