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

Tengo el siguiente problema:

  • la versión en el master funciona bien
  • la versión de la última label 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?

A partir de git 2.7, puede usar los arguments –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 testing, 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 testing, diga git bisect-fixed o git bisect-unfixed según corresponda.

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 

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

He encontrado una syntax Bash válida para negar el código de salida del progtwig 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 testings ejecutadas por prove .

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/

Git ahora te permite usar lo old y lo new sin definirlos primero. Tienes que llamar a git bisect start sin commits como arguments 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.