2010-01-12 7 views
10

Ich habe versucht, git bisect in letzter Zeit zu verwenden, aber es hat einfach nicht funktioniert. Der Baum blieb im Master und ich sah keinerlei Ausgabe von git bisect. Hier ist, was ich versucht habe:git Halbierung funktioniert nicht, keine Ausgabe

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

Ich habe dies auf zwei verschiedene Repos versucht. Hat nicht funktioniert. git --version ist 1.6.3.3 auf Ubuntu 9.10 Irgendwelche Ideen?

+0

Welche Argumente werden an "gut" und "schlecht" weitergegeben? Ist der "schlechte" Commit ein Nachkomme des "guten" Commits? –

+0

Ich habe das gleiche Problem. Keine Ausgabe nach der Ausführung von "git bisect start" und dann entweder "git bisect bad" oder "git bisect good". 'git bisect visualisieren' Ausgänge' Sie müssen mir mindestens eine gute und eine schlechte Revision geben. (Sie können "git bisect bad" und "git bisect good" dafür verwenden.) 'Egal wie oft ich' git bisect good' oder 'git bisect bad' mache –

Antwort

16

Einführung in Git WinkelHalbierende

"git bisect" kann zunächst etwas verwirrend sein. Sobald Sie verstehen, was es tut, wird es einfach sein.

Die typische Szenerie für "git bisect" ist: Ein Fehler wurde gerade entdeckt. Sie möchten herausfinden, welcher rev den Fehler verursacht hat. Sie wissen, dass der Fehler in der letzten Version vorhanden ist, aber in einer früheren Version eingeführt wurde. Sie müssen einen Weg finden, um herauszufinden, ob der Fehler existiert. Dies kann ein automatischer Test sein, oder es kann ein Test sein, den Sie von Hand ausführen.

Los geht's. Ausgehend von dem neuesten rev in Ihrer Branche, Ausgabe:

git bisect start 

Und dann git sagen, dass die aktuelle Version schlecht zu sein ist bekannt:

git bisect bad 

Jetzt brauchen wir eine gute U zu finden. Überprüfen Sie etwas, das alt genug ist, um den Fehler nicht zu haben. Wenn Sie denken, dass 32 Umdrehungen vor gut sein sollte, dann:

git checkout HEAD~32 

und führen Sie den Test, um zu sehen, wenn sie den Fehler hat. Wenn es den Fehler hat, müssen Sie eine noch ältere Version versuchen (geben Sie einfach "git checkout HEAD ~ 32" erneut aus). Sobald Sie auf einem rev landen, die nicht den Fehler hat, dann gilt:

git bisect good 

Das git sagt, dass die aktuelle Version ist gut. Git wird sofort einen rev zwischen dem guten rev und dem schlechten rev überprüfen; Sie werden ausgegeben, siehe zum Beispiel:

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

Ihren Test ausführen, und in Abhängigkeit von den Ergebnissen des Tests, die Ausgabe einer dieser Befehle:

  • 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 wird weiterhin zu unterscheiden ändern Nt dreht, und Sie werden es weiter gut, schlecht oder überspringen sagen. Wenn git schließlich herausfindet, welche rev begann die alle Mühe, werden Sie so etwas wie dieses:

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 

Und Ihre aktuellen rev wird es auf dem ersten schlechten begehen.

Lauf git "hands off"

bisect Wenn Ihr Test automatisch, dann können Sie git lassen die ganze Arbeit tun.Tun Sie alles, was Sie getan haben, um oben zu beginnen:

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

Und jetzt für die Magie. Sie benötigen lediglich ein Testprogramm, das den Exit-Code "0" für den Erfolg und 1 (beispielsweise) für den Fehler zurückgibt. Sagen Sie git über Ihren Test: "git bisect bad"

git bisect run tests/mytest.rb 

Git wird nun den Test ausführen, um die Ergebnisse mit automatisch ein "git bisect gut" zu tun oder ein Dies wird so lange fortgesetzt, bis das Commit, das den Fehler eingeführt hat, gefunden wurde. Alles, was Sie tun müssen, ist sich zurücklehnen und beobachten.

Wenn Sie getan

Wenn Sie fertig sind, Ausgabe:

git bisect reset 

Git werden Sie setzen, wo Sie angefangen.

+0

' git bisect run' wird weiter laufen bis die Commit, das den Bug einführt, wird gefunden. Nicht bis zur ersten schlechten Umdrehung. – Lorenz

+0

@Lorenz, ich meinte zuerst in der Reihenfolge von commit, nicht zuerst von bisect überprüft. Ich gebe die Formulierung ist zweideutig - guter Fang. Ich werde es aktualisieren. –

+0

Dies ist eine Einführung, wie git bisect funktioniert und nicht die Antwort auf das Problem. Das Problem ist, dass git bisect nicht richtig funktioniert, obwohl es wie in den allgemeinen Anweisungen beschrieben verwendet wird. Es ist eine gute Einführung. –

1

Was Sie versuchten, scheiterte, weil Sie ihm gesagt haben, dass der gleiche troeish sowohl gut als auch schlecht war. das macht natürlich keinen Sinn

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 

Da eine gegebene treeish unmöglich gut sein kann und schlechte git nur vorausgesetzt, dass Sie selbst wurden zu korrigieren.

Der Schlüssel hier ist, dass, wenn Sie kein Baumeisch git angeben, Sie meinen, die aktuelle.

Ein besserer Weg, dies getan zu haben, wäre, zuerst den Baum eines Commit zu finden, wo die Dinge funktionieren. dann ...

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

danach beginnt die Halbierung automatisch zu laufen. Sie müssen immer noch damit interagieren und ihm den Status der halbierten Commits mitteilen (oder ein Skript schreiben, um es zu automatisieren).