Come posso eseguire il debug di problemi relativi a git / git-shell?


148

Come posso avere alcune informazioni di debug riguardanti git / git-shell?

Ho avuto un problema, che user1poteva clonare un repository senza problemi, mentre user2poteva clonarne solo uno vuoto. Avevo impostato GIT_TRACE=1, ma non è stato detto nulla di utile.

Alla fine, dopo una lunga prova ed errore, si è scoperto che si trattava di un problema di autorizzazione su un file. Un messaggio di errore appropriato potrebbe cortocircuitare questo problema.


Nota: inoltre GIT_CURL_VERBOSE, con Git 2.9.x / 2.10 avrai a disposizione GIT_TRACE_CURL. Vedi la mia risposta qui sotto .
VonC,

E (Q2 2019, tre anni dopo GIT_TRACE_CURL), ora hai trace2. Esempio: git config --global trace2.normalTarget ~/log.normal. Vedi la mia (nuova) risposta di seguito .
VonC,

Risposte:


212

Per un output ancora più dettagliato usare quanto segue:

GIT_CURL_VERBOSE=1 GIT_TRACE=1 git pull origin master


53
Ci sono alcune opzioni GIT_TRACE, oltre a quella principale. Ecco l'opzione über-verbose:set -x; GIT_TRACE=2 GIT_CURL_VERBOSE=2 GIT_TRACE_PERFORMANCE=2 GIT_TRACE_PACK_ACCESS=2 GIT_TRACE_PACKET=2 GIT_TRACE_PACKFILE=2 GIT_TRACE_SETUP=2 GIT_TRACE_SHALLOW=2 git pull origin master -v -v; set +x
Paul Irish

2
Come e dove impostare queste variabili?
Hunsu,

È solo un'intera linea che puoi incollare nel tuo terminale. È necessario sostituire la git pull origin masterparte con il comando che si desidera eseguire.
Aeolun

1
Su quali piattaforme funziona? Certamente non Windows.
cowlinator,

8
Su Windows puoi impostare queste variabili, una alla volta (una per riga), in questo modo:set GIT_CURL_VERBOSE=1 set GIT_TRACE=1 git pull origin master
cowlinator

85

Debug

Git ha un set abbastanza completo di tracce che puoi usare per eseguire il debug dei tuoi problemi git.

Per attivarli, è possibile definire le seguenti variabili:

  • GIT_TRACE per tracce generali,
  • GIT_TRACE_PACK_ACCESS per tracciare l'accesso al pacchetto di file,
  • GIT_TRACE_PACKET per la traccia a livello di pacchetto per le operazioni di rete,
  • GIT_TRACE_PERFORMANCE per la registrazione dei dati sulle prestazioni,
  • GIT_TRACE_SETUP per informazioni sulla scoperta del repository e dell'ambiente con cui interagisce,
  • GIT_MERGE_VERBOSITY per il debug della strategia di unione ricorsiva (valori: 0-5),
  • GIT_CURL_VERBOSEper la registrazione di tutti i messaggi di arricciatura (equivalenti a curl -v),
  • GIT_TRACE_SHALLOW per il debug di recupero / clonazione di repository superficiali.

I valori possibili possono includere:

  • true, 1O 2scrivere a stderr,
  • un percorso assoluto che inizia con /per tracciare l'output nel file specificato.

Per maggiori dettagli, vedi: Git Internals - Variabili d'ambiente


SSH

Per problemi con SSH, prova i seguenti comandi:

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

o utilizzare sshper convalidare le proprie credenziali, ad es

ssh -vvvT git@github.com

o sulla porta HTTPS:

ssh -vvvT -p 443 git@ssh.github.com

Nota: ridurre il numero di -vper ridurre il livello di verbosità.


Esempi

$ 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
...

2
Il passaggio echo 'ssh -vvv $*' > ssh && chmod +x ssha echo 'ssh -vvv "$@"' > ssh && chmod +x sshdovrebbe essere più sicuro nel caso limite in cui un singolo parametro ha uno spazio al suo interno.
Alexander Bird,

46

prova questo:

GIT_TRACE=1 git pull origin master

40

Se è su SSH, è possibile utilizzare quanto segue:

Per un livello di debug più elevato per digitare -vv o -vvv rispettivamente per i livelli di debug 2 e 3:

# 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>

Ciò è utile soprattutto per gestire i problemi di chiave pubblica e privata con il server. Puoi usare questo comando per qualsiasi comando git, non solo 'git clone'.


Sì, funziona perfettamente. Meglio di altri. Sì, funziona perfettamente. Meglio di altri.
BMW,

Questo sarebbe molto utile in quanto devo risolvere un problema chiave ora, ma non funziona per me con git 1.8.3.1 e OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips 11 febbraio 2013 su CentOS Linux versione 7.2.1511 (Nucleo). :(
Greg Dubicki,

@GregDubicki Strange. Fammi sapere cosa funziona per te in modo che io possa aggiornare la risposta.
Basil Musa,

1
Su Windows utilizzare set GIT_SSH_COMMAND=ssh -v(senza virgolette).
jansohn,

18

Git 2.9.x / 2.10 (Q3 2016) aggiunge un'altra opzione di debug: GIT_TRACE_CURL.

Vedi commit 73e57aa , commit 74c682d (23 maggio 2016) di Elia Pinto ( devzero2000) .
Aiutato da: Torsten Bögershausen ( tboegi) , Ramsay Jones, Junio ​​C Hamano ( gitster) , Eric Sunshine ( sunshineco) e Jeff King ( peff) .
(Unita da Junio ​​C Hamano - gitster- in commit 2f84df2 , 06 lug 2016)

http.c: implementa la GIT_TRACE_CURLvariabile d'ambiente

Implementare la GIT_TRACE_CURLvariabile d'ambiente per consentire un maggior grado di dettaglio GIT_CURL_VERBOSE, in particolare l'intestazione di trasporto completa e tutti i payload di dati scambiati.
Potrebbe essere utile se una particolare situazione potrebbe richiedere un'analisi di debug più approfondita.

La documentazione indicherà:

GIT_TRACE_CURL

Abilita un dump di traccia completo e arricciato di tutti i dati in entrata e in uscita, comprese le informazioni descrittive, del protocollo di trasporto git.
Questo è simile al fare curl --trace-asciisulla riga di comando.

Questa opzione sostituisce l'impostazione della GIT_CURL_VERBOSEvariabile di ambiente.


Puoi vedere quella nuova opzione usata in questa risposta , ma anche nei test Git 2.11 (Q4 2016):

Vedi commit 14e2411 , commit 81590bf , commit 4527aa1 , commit 4eee6c6 (07 set 2016) di Elia Pinto ( devzero2000) .
(Unita da Junio ​​C Hamano - gitster- in commit 930b67e , 12 set 2016)

Utilizzare la nuova GIT_TRACE_CURLvariabile di ambiente anziché quella obsoleta GIT_CURL_VERBOSE .

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

Questa funzionalità è fantastica! L'unico punto è l'output ASCII (dove stampano tutto ciò che non è un (ch >= 0x20) && (ch < 0x80)punto. ) e nessun modo di output esadecimale per i dati http.
Kinornirvana,

8

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

trace2: crea una nuova funzione di traccia combinata

Crea una nuova funzione di traccia unificata per git.
L'intento finale è quello di sostituire la corrente trace_printf*e le trace_performance*routine con un insieme unificato di git_trace2*routine.

Oltre alla solita API in stile printf, trace2fornisce verbi di eventi di livello superiore con campi fissi che consentono la scrittura di dati strutturati.
Ciò semplifica la post-elaborazione e l'analisi di strumenti esterni.

Trace2 definisce 3 target di output.
Questi vengono impostati utilizzando le variabili di ambiente "GIT_TR2 ", " GIT_TR2_PERF" e " GIT_TR2_EVENT".
Questi possono essere impostati su "1" o su un nome di percorso assoluto (proprio come l'attuale GIT_TRACE).

Nota: per quanto riguarda il nome della variabile di ambiente, utilizzare sempre GIT_TRACExxx, nonGIT_TRxxx .
Quindi in realtà GIT_TRACE2, GIT_TRACE2_PERFo GIT_TRACE2_EVENT.
Vedere la ridenominazione Git 2.22 menzionata più avanti di seguito.

Quello che segue è l' iniziale lavoro su questa nuova funzionalità di traccia, con i vecchi nomi delle variabili di ambiente:

  • GIT_TR2è destinato a sostituire GIT_TRACEe registra i dati di riepilogo dei comandi.

  • GIT_TR2_PERF è inteso come sostituto di GIT_TRACE_PERFORMANCE .
    Estende l'output con colonne per il processo di comando, thread, repo, tempi trascorsi assoluti e relativi. Riporta eventi per l'avvio / arresto del processo figlio, l'avvio / arresto del thread e l'annidamento della funzione per thread.

  • GIT_TR2_EVENTè un nuovo formato strutturato. Scrive i dati degli eventi come una serie di record JSON.

Le chiamate alle funzioni trace2 accedono a una delle 3 destinazioni di output abilitate senza la necessità di chiamare diverse trace_printf* o trace_performance*routine.

Vedi commit a4d3a28 (21 mar 2019) di Josh Steadmon ( steadmon) .
(Unito da Junio ​​C Hamano - gitster- in commit 1b40314 , 08 maggio 2019)

trace2: scrive nelle destinazioni della directory

Quando il valore di una variabile d'ambiente trace2 è un percorso assoluto che fa riferimento a una directory esistente, scrivere l'output su file (uno per processo) sotto la directory specificata.
I file verranno denominati in base al componente finale del SID trace2, seguito da un contatore per evitare potenziali collisioni.

Ciò rende più conveniente raccogliere tracce per ogni invocazione git impostando incondizionatamente l' trace2envvar rilevante su un nome di directory costante.


Vedi anche commit f672dee (29 aprile 2019) e commit 81567ca , commit 08881b9 , commit bad229a , commit 26c6f25 , commit bce9db6 , commit 800a7f9 , commit a7bc01e , commit 39f4317 , commit a089724 , commit 1703751 (15 aprile 2019) di Jeff Hostetler ( jeffhostetler) .
(Unita da Junio ​​C Hamano - gitster- in commit 5b2d1c0 , 13 maggio 2019)

La nuova documentazione ora include le impostazioni di configurazione che vengono lette solo dal sistema e dai file di configurazione globali (il che significa che i file di configurazione del repository locale e di lavoro e gli -cargomenti della riga di comando non vengono rispettati).

Esempio :

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

i rendimenti

$ 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

E per misurare le prestazioni :

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

i rendimenti

$ 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

Come documentato in Git 2.23 (3 ° trimestre 2019), la variabile d'ambiente da usare è GIT_TRACE2.

Vedi commit 6114a40 (26 giu 2019) di Carlo Marcelo Arenas Belón ( carenas) .
Vedi commit 3efa1c6 (12 giu 2019) di Ævar Arnfjörð Bjarmason ( avar) .
(Unito da Junio ​​C Hamano - gitster- in commit e9eaaa4 , 09 lug 2019)

Ciò segue il lavoro svolto in Git 2.22: commit 4e0d3aa , commit e4b75d6 (19 maggio 2019) di SZEDER Gábor ( szeder) .
(Unito da Junio ​​C Hamano - gitster- in commit 463dca6 , 30 maggio 2019)

trace2: rinomina le variabili di ambiente in GIT_TRACE2 *

Per una variabile di ambiente che dovrebbe essere impostata dagli utenti, la GIT_TR2* sono semplicemente poco chiare, incoerenti e brutte.

La maggior parte delle stabiliti GIT_*variabili d'ambiente non utilizzare abbreviazioni, e nel caso dei pochi che fare ( GIT_DIR, GIT_COMMON_DIR, GIT_DIFF_OPTS) è abbastanza evidente che cosa le abbreviazioni ( DIRe OPTS) rappresentano.
Ma cosa faTR ? Traccia, tradizionale, trailer, transazione, trasferimento, trasformazione, transizione, traduzione, trapianto, trasporto, attraversamento, albero, trigger, troncamento, fiducia o ...?!

La funzione trace2, come suggerisce il suffisso '2' nel suo nome, dovrebbe eventualmente sostituire la funzione di traccia originale di Git.
È ragionevole aspettarsi che le variabili d'ambiente corrispondenti seguano l'esempio, e dopo le GIT_TRACEvariabili originali vengono chiamate GIT_TRACE2; non esiste una cosa del genere ' GIT_TR'.

Tutte le variabili di configurazione specifiche di trace2 sono, molto sensatamente, nella sezione ' trace2', non in ' tr2'.

OTOH, non otteniamo assolutamente nulla omettendo gli ultimi tre caratteri di "trace" dai nomi di queste variabili di ambiente .

Quindi, rinominiamo tutte GIT_TR2*le variabili di ambiente in GIT_TRACE2*, prima che diventino una versione stabile.


Git 2.24 (Q3 2019) migliora l'inizializzazione del repository Git.

Vedi commit 22932d9 , commit 5732f2b , commit 58ebccb (06 agosto 2019) di Jeff King ( peff) .
(Unito da Junio ​​C Hamano - gitster- in commit b4a1eec , 09 set 2019)

common-main: ritarda l'inizializzazione di trace2

Inizializziamo il trace2sistema nella funzione main () comune in modo che tutti i programmi (anche quelli che non sono integrati) consentano la traccia.

Ma l' trace2avvio è relativamente pesante, poiché dobbiamo effettivamente leggere la configurazione su disco per decidere se tracciare.
Ciò può causare interazioni impreviste con altre inizializzazioni principali comuni. Ad esempio, finiremo nel codice di configurazione prima di chiamare initialize_the_repository(), e il solito invariante che the_repositorynon è mai NULL non verrà trattenuto.

trace2Spingiamo ulteriormente l' inizializzazione in common-main, appena prima di eseguirla cmd_main().


Git 2.24 (Q4 2019) si assicura anche che l'output dal trace2sottosistema sia formattato in modo più grazioso ora.

Vedi commit 742ed63 , commit e344305 , commit c2b890a (09 ago 2019), commit ad43e37 , commit 04f10d3 , commit da4589c (08 ago 2019) e commit 371df1b (31 luglio 2019) di Jeff Hostetler ( jeffhostetler) .
(Unita da Junio ​​C Hamano - gitster- in commit 93fc876 , 30 set 2019)

E ancora Git 2.24

Vedi commit 87db61a , commit 83e57b0 (04 ott 2019) e commit 2254101 , commit 3d4548e (03 ott 2019) di Josh Steadmon ( steadmon) .
(Unita da Junio ​​C Hamano - gitster- in commit d0ce4d9 , 15 ott 2019)

trace2: scarta nuove tracce se la directory di destinazione contiene troppi file

Firmato-fuori-da: Josh Steadmon

trace2può scrivere file in una directory di destinazione.
Con un uso intenso, questa directory può riempire di file, causando difficoltà per i sistemi di elaborazione delle tracce.

Questa patch aggiunge un'opzione di configurazione ( trace2.maxFiles) per impostare un numero massimo di file che trace2verranno scritti in una directory di destinazione.

Il seguente comportamento è abilitato quando maxFilesè impostato su un numero intero positivo:

  • Quando trace2scrivere un file in una directory di destinazione, verificare innanzitutto se le tracce devono essere eliminate. Le tracce devono essere eliminate se:

    • c'è un file sentinella che dichiara che ci sono troppi file
    • OPPURE, il numero di file supera trace2.maxFiles.
      In quest'ultimo caso, creiamo un file sentinella chiamato git-trace2-discardper accelerare i controlli futuri.

Il presupposto è che un sistema separato di elaborazione delle tracce abbia a che fare con le tracce generate; una volta elaborato e rimosso il file sentinella, dovrebbe essere sicuro generare di nuovo nuovi file di traccia.

Il valore predefinito per trace2.maxFilesè zero, che disabilita il controllo del conteggio dei file.

La configurazione può anche essere sovrascritto con una nuova variabile d'ambiente: GIT_TRACE2_MAX_FILES.


E Git 2.24 (Q4 2019) insegna trace2 sugli git pushstadi.

Vedi commit 25e4b80 , commit 5fc3118 (02 ott 2019) di Josh Steadmon ( steadmon) .
(Unita da Junio ​​C Hamano - gitster- in commit 3b9ec27 , 15 ott 2019)

push: aggiunge la strumentazione trace2

Firmato-fuori-da: Josh Steadmon

Aggiungi le tracce trace2 in transport.ce builtin/push.cper monitorare meglio il tempo trascorso in varie fasi di push:

  • Elenco di riferimento
  • Verifica dei sottomoduli
  • Spingendo sottomoduli
  • Spingendo i riferimenti

Con Git 2.25 (Q1 2020), alcuni dei file Documentation/technicalvengono spostati nei *.hfile di intestazione .

Vedi commit 6c51cb5 , commit d95a77d , commit bbcfa30 , commit f1ecbe0 , commit 4c4066d , commit 7db0305 , commettere f3b9055 , commettere 971b1f2 , commettere 13aa9c8 , commettere c0be43f , commettere 19ef3dd , commettere 301d595 , commettere 3a1b341 , commettere 126c1cc , commettere d27eb35 , commettere 405c6b1 , commettono d3d7172 , commit 3f1480b , commit 266f03e , commit 13c4d7e(17 nov 2019) di Heba Waly ( HebaWaly) .
(Unita da Junio ​​C Hamano - gitster- in commit 26c816a , 16 dic 2019)

trace2: sposta doc in trace2.h

Firmato-fuori-da: Heba Waly

Sposta la documentazione delle funzioni da Documentation/technical/api-trace2.txta trace2.hpoiché è più facile per gli sviluppatori trovare le informazioni sull'utilizzo accanto al codice invece di cercarle in un altro file doc.

Viene rimossa solo la sezione della documentazione delle funzioni Documentation/technical/api-trace2.txtpoiché il file è pieno di dettagli che sembravano più appropriati trovarsi in un file doc separato così com'è, con un collegamento al file doc aggiunto in trace2.h. Inoltre, il documento delle funzioni viene rimosso per evitare di avere informazioni ridondanti che saranno difficili da sincronizzare con la documentazione nel file di intestazione.

(sebbene tale riorganizzazione abbia avuto un effetto collaterale su un altro comando, spiegato e corretto con Git 2.25.2 (marzo 2020) in commit cc4f2eb (14 feb 2020) di Jeff King ( peff) .
(Fuso da Junio ​​C Hamano - gitster- in commit 1235384 , 17 febbraio 2020) )


Con Git 2.27 (Q2 2020): miglioramento di Trace2 per consentire la registrazione delle variabili di ambiente .

Vedere commit 3d3adaa (20 marzo 2020) di Josh Steadmon ( steadmon) .
(Unita da Junio ​​C Hamano - gitster- in commit 810dc64 , 22 aprile 2020)

trace2: insegna a Git a registrare le variabili di ambiente

Firmato-fuori: Josh Steadmon
Acked-by: Jeff Hostetler

Tramite trace2, Git può già registrare interessanti parametri di configurazione (vedere la trace2_cmd_list_config()funzione). Tuttavia, ciò può garantire un'immagine incompleta poiché molti parametri di configurazione consentono anche sostituzioni tramite variabili di ambiente.

Per consentire registri più completi, aggiungiamo una nuova trace2_cmd_list_env_vars()funzione e un'implementazione di supporto, modellata sull'implementazione di registrazione dei parametri di configurazione preesistente.


Con Git 2.27 (2 ° trimestre 2020), insegnare ai codepati che mostrano i contatori dei progressi per utilizzare anche start_progress()le stop_progress()chiamate e come " region" da tracciare.

Vedi commit 98a1364 (12 maggio 2020) di Emily Shaffer ( nasamuffin) .
(Unita da Junio ​​C Hamano - gitster- in commit d98abce , 14 maggio 2020)

trace2: registra il tempo di avanzamento e la velocità effettiva

Firmato-fuori-da: Emily Shaffer

Invece di insegnare una sola operazione, come ' git fetch', come scrivere il throughput sulle tracce, possiamo imparare una vasta gamma di operazioni dell'utente che possono sembrare lente aggiungendo strumenti alla stessa libreria di avanzamento .

Le operazioni che mostrano progressi sono probabilmente lente e il tipo di cose che vogliamo comunque monitorare per le prestazioni.

Mostrando il conteggio degli oggetti e le dimensioni del trasferimento dei dati, dovremmo essere in grado di effettuare alcune misurazioni derivate per garantire che le operazioni si ridimensionino nel modo previsto.

E:

Con Git 2.27 (Q2 2020), la correzione dell'ultimo minuto per la nostra recente modifica per consentire l'uso dell'API di avanzamento come area tracciabile.

Vedi commit 3af029c (15 maggio 2020) di Derrick Stolee ( derrickstolee) .
(Unita da Junio ​​C Hamano - gitster- in commit 85d6e28 , 20 maggio 2020)

progress: chiama trace2_region_leave() solo dopo aver chiamato_enter()

Firmato-fuori-da: Derrick Stolee

Un utente dell'API progress chiama in modo start_progress()condizionale e dipende da display_progress()estop_progress() funzioni per diventare non operativo quando start_progress()non è stato chiamato.

Come abbiamo aggiunto una chiamata trace2_region_enter()astart_progress() le chiamate verso altre chiamate API da trace2 le funzioni API di avanzamento devono fare in modo che queste chiamate trace2 vengono ignorati quando start_progress()non è stato invitato lo struct progresso.

In particolare, non chiamare trace2_region_leave()da stop_progress()quando non abbiamo chiamato start_progress(), che avrebbe chiamato la corrispondenza trace2_region_enter().


4

Hai provato ad aggiungere l' -voperatore verbose ( ) durante la clonazione?

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


2

Per le versioni precedenti di git (1.8 e precedenti)

Non sono riuscito a trovare un modo adatto per abilitare il debug SSH nelle versioni git e ssh precedenti. Ho cercato le variabili di ambiente usandoltrace -e getenv ... e non sono riuscito a trovare alcuna combinazione di variabili GIT_TRACE o SSH_DEBUG che funzionasse.

Invece ecco una ricetta per iniettare temporaneamente 'ssh -v' nella sequenza git-> ssh:

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

Ecco l'output dalla versione 1.8.3 di git con la versione ssh OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 feb 2013 clonando un repository 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'
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.