2010-01-12 4 views
10

Ultimamente ho provato a usare git bisect, ma non ha funzionato. L'albero è rimasto nel master e non ho visto nessuna uscita da git bisect. Ecco cosa ho provato:git bisect non funziona, nessuna uscita

git bisect start 
git bisect bad # no output, tried a couple of times 
git bisect good # no output 
git bisect reset #-> Already on 'master' 

Ho provato questo su due diversi repository. Non ha funzionato git --version è 1.6.3.3 su Ubuntu 9.10 Qualche idea?

+0

Quali argomenti stai passando a "buono" e "cattivo"? Il "cattivo" commette un discendente del commit "buono"? –

+0

Sto avendo lo stesso problema. Nessun output dopo aver eseguito 'git bisect start' e quindi' git bisect bad' o 'git bisect good'. 'git bisect visualize' outputs 'Devi darmi almeno una buona e una cattiva revisione. (Puoi usare "git bisect bad" e "git bisect good" per quello.) "Non importa quante volte faccio' git bisect good' o 'git bisect bad' –

risposta

16

Introduzione a Git Bisect

"git bisect" può essere un po 'di confusione in un primo momento. Una volta compreso ciò che fa, sarà facile.

Il tipico scenerio per "git bisect" è: un bug è stato appena scoperto. Vuoi scoprire quale rev ha introdotto il bug. Sai che il bug esiste nell'ultimo rev, ma è stato introdotto in un precedente rev. Avrai bisogno di un modo per scoprire se il bug esiste o meno. Questo può essere un test automatico o può essere un test eseguito a mano.

Iniziamo. A partire dal più recente giro nel vostro ramo, problema:

git bisect start 

e poi dire git che la versione corrente è noto per essere un male:

git bisect bad 

Ora abbiamo bisogno di trovare un buon giro. Controlla una cosa abbastanza vecchia da non avere il bug. Se si pensa che 32 giri fa dovrebbe essere buono, quindi:

git checkout HEAD~32 

ed eseguire il test per vedere se ha il bug. Se ha il bug, dovrai provare un rev più vecchio (basta "git checkout HEAD ~ 32" di nuovo). Non appena si terra su un giro che non ha il bug, quindi:

git bisect good 

che racconta git che l'attuale versione è buona. Git verificherà immediatamente un giro tra la buona rotazione e la brutta piega; vedrete in uscita, ad esempio:

$ git bisect good 
Bisecting: 7 revisions left to test after this (roughly 3 steps) 
[909ba8cd7698720d00b2d10738f6d970a8955be4] Added convenience delegators to Cache 

Esegui il test, e, a seconda dei risultati del test, eseguire uno di questi comandi:

  • git bisect good # the test passed
  • git bisect bad # the test failed
  • git bisect skip # we can't run the test on this rev for some reason (doesn't compile, etc.)

Git continuerà a cambiare a differe nt revs, e continuerai a dirlo bene, male o saltare. Quando git finalmente capisce che giri ha iniziato tutti i problemi, si otterrà qualcosa di simile:

b25ab3cee963f4738264c9c9b5a8d1a344a94623 is the first bad commit 
commit b25ab3cee963f4738264c9c9b5a8d1a344a94623 
Author: Wayne Conrad <[email protected]> 
Date: Fri Dec 25 18:20:54 2009 -0700 

    More tests and refactoring 

:040000 040000 6ff7502d5828598af55c7517fd9626ba019b16aa 39f346cb5a289cdb0955fcbba552f40e704b7e65 M  routecalc 

E il vostro giro corrente sarà lì, al primo cattivo commettere.

esecuzione git bisect "giù le mani"

Se il test è automatico, allora si può lasciare che git fare tutto il lavoro.Fai tutto ciò che hai fatto per iniziare sopra:

git bisect start 
git bisect bad 
git checkout HEAD~32 # or however far back it takes to find a good rev 
git bisect good 

E ora per la magia. Tutto ciò che serve è un programma di test che restituisca il codice di uscita "0" per il successo e 1 (ad esempio) per il fallimento. Dillo git circa il test: "git bisect cattivo"

git bisect run tests/mytest.rb 

Git verrà eseguito il test, utilizzando i risultati per fare automaticamente un "git bisect buono" o un Continuerà a farlo finché non verrà trovato il commit che ha introdotto il bug. Tutto quello che devi fare è sederti e guardare.

Quando hai finito

Quando hai finito, problema:

git bisect reset 

Git vi metterà di nuovo al punto di partenza.

+0

' git bisect run' continuerà a funzionare fino a quando commit che introduce il bug è stato trovato. Non fino alla prima brutta riv. – Lorenz

+0

@Lorenz, intendevo prima in ordine di commit, non prima controllato da bisect. Ammetto che la formulazione è ambigua - buona presa. Lo aggiornerò. –

+0

Questa è un'introduzione a come funziona git bisect e non la risposta al problema. Il problema è che git bisect non funziona correttamente nonostante l'uso come le istruzioni generali descrivono. Comunque è una buona introduzione. –

1

Quello che hai provato fallito perché hai detto che lo stesso albero era buono e cattivo. che ovviamente non ha alcun senso

git bisect start # tells git you want to do a bisect operation 
git bisect bad # tells git the current treesh (HEAD) is bad 
git bisect good # tells git the current treeish (HEAD) is good 

Perché un dato treeish non può assolutamente essere buoni e cattivi git solo assume stavi correggendo te stesso.

La chiave qui è che se non si specifica un git treeish si presume che si intenda quello corrente.

Un modo migliore per farlo sarebbe quello di trovare prima il treeish di un commit in cui le cose funzionano. quindi ...

git bisect start 
git bisect bad # tells it HEAD is bad 
git bisect good abc123 # treeish of the good commit 

dopo che la bisecatura inizierà a funzionare automaticamente. Dovrai comunque interagire con esso e dirlo comunque lo stato del bisected commit (o scrivere uno script per automatizzarlo).