git bisect no funciona, sin salida

Question

Intenté utilizar git bisect últimamente, pero simplemente no funcionó. El árbol permaneció en el maestro y no vi ninguna salida desde git bisect en absoluto. Esto es lo que he intentado:

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

Intenté esto en dos repositorios diferentes. No funcionó git --version es 1.6.3.3 en Ubuntu 9.10 ¿Alguna idea?

Answer 1

Introducción a Git Bisecar

"git bisect" puede ser un poco confuso al principio. Una vez que entiendas lo que hace, será fácil.

El escenario típico para "git bisect" es: Se acaba de descubrir un error. Desea averiguar qué rev introdujo el error. Usted sabe que el error existe en la última revisión, pero se introdujo en una revisión previa. Necesitará una forma de averiguar si el error existe o no. Esto puede ser una prueba automática, o puede ser una prueba que ejecuta a mano.

Comencemos. A partir de la última rev en su rama, ejecuta:

git bisect start 

Y luego decirle a Git que la versión actual se sabe que es malo:

git bisect bad 

Ahora tenemos que encontrar un buen rev. Comprueba uno con la edad suficiente para no tener el error. Si usted piensa que hace 32 revoluciones debe ser bueno, entonces:

git checkout HEAD~32 

y ejecutar su prueba para ver si tiene el error. Si tiene el error, deberás intentar una rev aún más vieja (simplemente ejecuta "git checkout HEAD ~ 32" nuevamente). Tan pronto como la tierra en un rev que no tiene el error, entonces:

git bisect good 

que le dice a Git que la versión actual es buena. Git inmediatamente revisará una revolución entre la buena rev y la mala rev; verá la salida, por ejemplo:

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

ejecutar su prueba, y dependiendo de los resultados de la prueba, emita uno de estos comandos:

• 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 continuará cambiando a diferente nt revoluciones, y seguirás diciéndolo bien, mal o salteando. Cuando git finalmente se da cuenta de lo que rev comenzó todo el problema, obtendrá algo como esto:

b25ab3cee963f4738264c9c9b5a8d1a344a94623 is the first bad commit 
commit b25ab3cee963f4738264c9c9b5a8d1a344a94623 
Author: Wayne Conrad <wconrad@yagni.com> 
Date: Fri Dec 25 18:20:54 2009 -0700 

    More tests and refactoring 

:040000 040000 6ff7502d5828598af55c7517fd9626ba019b16aa 39f346cb5a289cdb0955fcbba552f40e704b7e65 M  routecalc 

Y su rev ​​actual estará allí, en la primera entrega mala.

Correr git bisect "manos fuera"

Si la prueba es automático, entonces se puede dejar que git haga todo el trabajo.Haga todo lo que hizo para empezar:

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

Y ahora, para la magia. Todo lo que necesita es un programa de prueba que devuelva el código de salida "0" para el éxito y 1 (por ejemplo) para el fracaso. Dile a git acerca de su ensayo: "git bisect malo"

git bisect run tests/mytest.rb 

Git ahora se ejecutará la prueba, utilizando los resultados de hacerlo automáticamente un "git bisect buena" o una Seguirá haciéndolo hasta que se encuentre el compromiso que introdujo el error. Todo lo que tienes que hacer es sentarte y mirar.

Cuando haya terminado

Cuando haya terminado, ejecuta:

git bisect reset 

Git se pondrá de nuevo al punto de partida.

Answer 2

Lo que has intentado ha fallado porque dijiste que el mismo árbol era bueno y malo. que, evidentemente, no tiene ningún sentido

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 

Debido a que un treeish dada no puede ser bueno y malo Git simplemente asume que estaban corrigiendo a sí mismo.

La clave aquí es que si no especifica un treeth git se supone que quiere decir el actual.

Una mejor forma de hacerlo sería encontrar primero el árbol de un compromiso donde las cosas funcionen. entonces ...

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

después de que bisect comenzará a funcionar automáticamente. Sin embargo, aún tendrá que interactuar con él y contarle el estado de las confirmaciones bisectadas (o escribir un script para automatizarlo).