¿Cómo podría usar git bisect para encontrar la primera confirmación BUENA?

Tengo el siguiente problema:

• la versión masterfunciona bien
• la versión de la última etiqueta antes master(digamos last) tiene un error
• un colega necesita un parche para su lastrevisión de ese cierto error

Bueno. Pidamos a nuestro amigo git bisectla revisión que solucionó el error:

git bisect start
git bisect bad last
git bisect good master

Pero eso no va a funcionar:

Algunas buenas revoluciones no son antepasados ​​de las malas rev.
git bisect no puede funcionar correctamente en este caso.
¿Quizás confundes buenas y malas revoluciones?

¿Alguna pista para superar esto? ¿Me perdí algo en los documentos?

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

Por ejemplo, puede identificar una confirmación de resolució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 fixedo git bisect unfixedsegún corresponda.

Respuesta anterior, para versiones de git anteriores a 2.7

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

En ~/.gitconfigañada la siguiente:

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

Puede comenzar a identificar una confirmación de resolución de problemas así:

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

Mientras prueba, diga git bisect-fixedo git bisect-unfixedsegún corresponda.

Simplemente "engañaría" a git e intercambiaría significados de bueno <=> malo.

En otras palabras, considere "malo" como algo que no presenta el problema, por lo que esta no es la versión "buena" en la que basar su 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 runcomo lo he estado haciendo con el provecomando de Perl (que ejecuta pruebas automáticas), no tiene posibilidad de intercambiar goody bad. El éxito de las pruebas se informará como código de salida.

He encontrado una sintaxis de 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 realizadas prove.

Git ahora le permite usar oldy newsin definir primero de ellos. Tienes que llamar git bisect startsin confirmaciones como argumentos adicionales, luego iniciar correctamente la bisección llamando

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

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

Esto es esencialmente lo que @MarcH sugirió que se debería implementar.

Alias Git son una buena idea, sin embargo, los términos fixedy unfixedtener el mismo problema que goode bad: no se puede tener ellos sean compatibles con ambas regresiones y progresiones. Es fácil encontrar palabras que funcionen de cualquier manera: simplemente retírelas de la terminología de búsqueda binaria original, que es de naturaleza neutral sin preconcepción 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 pudieran simplemente reutilizar cualquiera de los términos existentes. La interfaz de usuario no es una preocupación de git en general: http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/