guide - ¿Por qué la rama ''git bisect'' no es consciente?

git commands pdf

Question

Estoy tratando de encontrar la fuente de un error que surgió desde que se cometió un día anterior en una rama de larga duración (que se lanzará mucho más tarde) llamada feature-x .

Aunque hay un error. Encuentro un comportamiento que no espero de mi script que podría haber sido introducido hasta ahora en cualquiera de los confirmaciones, específicamente porque las características de master se usan mucho en feature-x, pero menos en Master en sí.

Para probar este comportamiento, tengo que ejecutar mi script, dependiente.pl. Pero cuando bisect salta a la mitad del código, mi script no existe en Master y, por lo tanto, es imposible de probar.

Creo que esto se debe a que bisect te lleva a un estado sin cabeza, pero en este caso realmente quiero estar en el contexto de esta otra historia / conjunto de cambios, y no flotar en el éter.

Antes de que alguien salte para golpear el timbre que está haciendo mal , a nuestro equipo le gusta fusionar las ramas en estas situaciones, ya que la metáfora funciona bien para esta situación, no la rebase.

Voy a demostrar esto creando un ejemplo de repositorio:

git init

echo ''sub f { print $_; }'' > main.pl
git add .
git commit -a -m "inital commit"

git branch feature-x
git checkout feature-x
echo ''main::f(1)'' > dependent.pl
git add .
git commit -a -m "Starting work on feature X"
git tag dev-1.0

git checkout master
echo "sub f { return 1; }" > main.pl
git commit -a -m "sub f { return 1; }"
echo "sub f { return 2; }" > main.pl
git commit -a -m "sub f { return 2; }"
echo "sub f { return 3; }" > main.pl
git commit -a -m "sub f { return 3; }"

git tag release-1.0

git checkout feature-x
git merge master

echo ''print main::f();'' > dependent.pl
git commit -a -m "Updating call to f"

Así que ahora obtienes un repo que se ve así:

o Updating call to f ( Head of branch ''feature-x'' )
o Merge branch master onto feature-x
|/
| o sub f { return 3; } (TAG release-1.0) ( Head of branch ''master'' )
| o sub f { return 2; }
| o sub f { return 1; }
o | Starting work on feature X ( TAG ''dev-1.0'' )
 /|
  o initial commit

Así que ejecuto el comando git bisect start feature-x dev-1.0 esperando poder encontrar lo que rompió mi código en dependiente.pl, termino en commit ''sub f {return 2}'' sin mi historial de cambios desde feature-x (es decir, si ejecuto ls , todo lo que veo es main.pl y faltante a dependencia.pl).

Esto me pone en un estado no comprobable. No puedo saber si el compromiso actual rompió mi trabajo o no, ni puedo decir que los compromisos del maestro lo rompieron, así que no puedo decir que este compromiso sea bueno o malo.

¿Cómo puedo probar lo que rompió mi rama actual?

Answer 1

El problema aquí es que git bisect es consciente de la rama. Cuando le dices que "dependiente" es bueno y "prueba" es malo, y uno de los cambios entre ellos es un compromiso de combinación, sabe que para averiguar dónde se introdujo el problema, tendrá que analizarlo. comete a, b, yc - de lo contrario, todo lo que podría decirle es si está roto o no a partir de ese compromiso de fusión.

Parece que lo que está esperando es probar la combinación de confirmación b con los cambios de la otra rama, que es un contenido que no existe en ninguna confirmación, y git bisect solo le permite probar confirmaciones. Para probar ese contenido, tendría que hacer una serie de fusiones de prueba: desproteger b, fusionar dependiente, dejarle probar, luego revisar a o c, fusionar dependiente, dejarle probar nuevamente. Puede hacer muy fácilmente git merge --no-commit dependent una vez que lo haya dejado en commit b, luego hacer git reset --hard cuando haya terminado con las pruebas antes de ejecutar git bisect good/bad .

De lo contrario, si he entendido mal, usted espera que no pruebe ninguna confirmación en la rama fusionada, y que solo pruebe la confirmación de fusión en sí (no le importa cuál de a, b, o c lo rompió), simplemente dígale que todo en la rama fusionada es buena. Aún mejor si sabes que a, b, yc no tienen nada que ver con eso. ¡Entonces sabes sin siquiera probar que son buenos!

Pero lo único que no se puede esperar es que git ignore por completo las comillas a, b y c. No tiene absolutamente ninguna forma de saber si sus cambios son o no relevantes para su "error", y sus cambios son parte de la diferencia entre sus compromisos buenos y malos.