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


90

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?


1
Estoy corriendo git bisect run ...para automatizar la bisección. Así que no tengo la oportunidad de intercambiar las palabras goody bad(eso era demasiado obvio). ¿Cómo utilizar runpara encontrar la primera revisión buena?
Daniel Böhmer

@ DanielBöhmer: tienes que intercambiar términos dentro de tu script que se está ejecutando, ¿no?
eckes

El script ejecutado por git bisect rundevuelve bueno o malo como código de salida, no como una cadena. Vea mi respuesta que acabo de publicar a continuación.
Daniel Böhmer

@ DanielBöhmer: bueno, en ese caso tendrás que invertir el código de retorno, ¿no?
eckes

Correcto, eso es lo que se describe en mi respuesta.
Daniel Böhmer

Respuestas:


98

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.


5
Aparte, git no te permite crear alias de subcomandos. De ahí los guiones. Si realmente es (o se hace) posible, es de esperar que alguien actualice la respuesta.
Michael Wolf

3
Incluso si usa alias, la salida de git no lo hará, por lo que seguirá informando foo is the first bad commit, por lo que parece que todavía es necesario un entrenamiento temporal, ¿no?
ThomasW

2
Punto justo. (Voto a favor de tu comentario). Aunque aún así, es de esperar que sea al menos un poco menos de carga cognitiva adicional con la que lidiar, y como programadores ya tenemos bastante.
Michael Wolf

1
Recomiendo usar alias 'antes' y 'después'. De esa manera, no tendrá la sobrecarga cognitiva de hacer la inversión "cuando vea el error, debería escribir 'bueno'"; en su lugar, solo tiene la sobrecarga, probablemente menor, de recordar que está buscando la aparición / desaparición de un error (es decir, recordar qué tipo de cambio está buscando, "¿antes de qué?").
Jonas Kölker

1
@ JonasKölker, es una gran idea. Usé los alias sugeridos en la respuesta, así como bisect-after = bisect bady bisect-before = bisect good, según su recomendación. Ahora puedo usar cualquier conjunto de alias. Veremos cuál termino favoreciendo más después de algunos usos.
Gabriel Staples

47

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

2
Bueno, si lo piensas, no hay un significado general de lo que es bueno o malo (probablemente ni siquiera en la religión) ... solo depende de tus propósitos. De esta manera no es realmente una trampa, pero tal vez el pecado de Git (para permanecer en el tema religioso: D es elegir un término tan polémico en lugar de un "objetivo" / "origen" más neutral ... Pero sí, la filosofía puede ser mental. boggling ;-)
inger

Esta debe ser la primera vez que escucho que los errores pueden ser "buenos".
MarcH

1
Eso es lo que hice antes de encontrar esta pregunta. No lo voy a hacer más. Recuerde, solo se necesita una respuesta incorrecta antes de que toda la bisección salga mal. No tuerzas tu mente.
proski

20

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.


Estoy de acuerdo, prefiero no modificar mi caso de prueba, así que esto es perfecto.
seanlinsley

8

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.


1
Esta es la respuesta más relevante (para git moderno). Y el comando de inicio debería ser (según el enlace que compartió):git bisect start --term-new fixed --term-old broken
Sam Protsenko

Cierto. ¿Cuándo se introdujeron estas opciones? Me gustaría actualizar mi respuesta.
Michael Wolf

@MichaelWolf Aparecieron en la versión 2.7.0 .
GKFX

6

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/


From: git.github.io/rev_news/2015/07/08/edition-5 "Se están puliendo algunas series de parches para permitir que git bisect use un par de términos arbitrarios en lugar de buenos y malos, ..."
MarcH
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.