example - ¿Cómo podría usar git bisect para encontrar el primer BUEN compromiso?

git bisect example

Question

Tengo el siguiente problema:

• la versión en el master funciona bien
• la versión de la última etiqueta antes del master (decir la last ) tiene un error
• un colega necesita un parche para su last revisión para ese cierto error

Bueno. Preguntémosle a nuestro amigo git bisect por la revisión que corrigió el error:

git bisect start
git bisect bad last
git bisect good master

Pero eso no va a funcionar:

Algunas buenas revoluciones no son ancestros de la mala rev.
git bisect no puede funcionar correctamente en este caso.
¿Tal vez confundes las buenas y malas revoluciones?

¿Algún indicio para superar esto? ¿Me perdí algo en los documentos?

Answer 1

A partir de git 2.7, puede usar los argumentos --term-old y --term-new.

Por ejemplo, puede identificar un compromiso de corrección de problemas así:

git bisect start --term-new=fixed --term-old=unfixed
git bisect fixed master
git bisect unfixed $some-old-sha1

Mientras prueba, diga git bisect fixed o git bisect unfixed según corresponda.

Respuesta anterior, para versiones de git anteriores a 2.7

En lugar de entrenarte temporalmente para pensar que lo malo significa lo bueno y lo bueno significa malo, ¿por qué no crear algunos alias?

En ~/.gitconfig agregue lo siguiente:

[alias]
        bisect-fixed = bisect bad
        bisect-unfixed = bisect good

Puede comenzar a identificar un compromiso de solución de problemas de esta manera:

$ git bisect start
$ git bisect-fixed master
$ git bisect-unfixed $some-old-sha1

A medida que realiza la prueba, diga git bisect-fixed o git bisect-unfixed según corresponda.

Answer 2

Git ahora te permite usar lo old y lo new sin definirlos primero. Tienes que llamar a git bisect start sin commits como argumentos adicionales, luego comenzar correctamente la bisección llamando

git bisect old <rev>
git bisect new <rev>

https://git-scm.com/docs/git-bisect#_alternate_terms

Esto esencialmente es lo que @MarcH estaba sugiriendo que debería implementarse.

Answer 3

Los alias de Git son una buena idea, sin embargo, los términos fixed y unfixed fixed tienen el mismo problema que el good y el bad : no se puede hacer que sean compatibles con regresiones y progresiones. Es fácil encontrar palabras que funcionen en ambos sentidos: simplemente retírelas de la terminología de búsqueda binaria original que es de naturaleza neutral sin preconceptos de lo que es bueno o malo. Por ejemplo:

git config --global alias.bisect-high ''bisect bad''
git config --global alias.bisect-low  ''bisect good''

Con términos neutrales como estos, siempre puede escribir: git bisect-high (o git bisect-upper , o git-bisect max , ... ¡su elección!) Ya sea que esté buscando una regresión o una solución .

Lástima que los desarrolladores de git bisect no puedan simplemente reutilizar ninguno de los términos existentes. La interfaz de usuario no es una preocupación de git en términos generales: http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/

Answer 4

Si está usando git bisect run como he estado haciendo con el comando de prove de Perl (que ejecuta pruebas automáticas) no tiene posibilidad de intercambiar lo good y lo bad . El éxito de las pruebas se informará como código de salida.

He encontrado una sintaxis Bash válida para negar el código de salida del programa ejecutado por git bisect run :

git bisect start
git bisect bad HEAD                 # last revision known to PASS the tests
git bisect good $LAST_FAIL_REVISION # last revision known to FAIL the tests
git bisect run bash -c "! prove"

Esto me dio la primera revisión para pasar las pruebas ejecutadas por prove .

Answer 5

Simplemente "engañaría" a los idiotas y cambiaría los significados de los buenos <=> malos.

En otras palabras, considere "malo" como algo que no muestra el problema, por lo que esta no es la versión "buena" en la que basar el parche.

Bueno y malo son conceptos bastante subjetivos de todos modos, ¿verdad? :)

git bisect start
git bisect good last
git bisect bad master