La bisección termina con git diciéndome que la base de fusión es mala, ¿cómo puedo progresar ahora?

Tengo un problema con el núcleo principal de Linux y quiero encontrar el compromiso que introdujo el error con git-bisect para notificar al autor que su cambio introdujo un error.

Vi un compromiso bueno y malo y comencé la bisección. Los buenos commits son los que aún no tienen el error, los commits malos son aquellos en los que ya se introdujo el error. La extracción más reciente del tree de Linus todavía tiene el error, así que supongo que aún no hay una solución para el error, por eso creo que es importante notificar al autor.

Sin embargo, a medida que avanzaba con la bisección y procedí a probar todas las confirmaciones en el path (no se saltaron las confirmaciones con "git bisect skip", todas fueron evaluadas como buenas o malas), en un momento me sorprendió con la siguiente post:

The merge base 7089db84e356562f8ba737c29e472cc42d530dbc is bad. This means the bug has been fixed between 7089db84e356562f8ba737c29e472cc42d530dbc and [02c3de1105228e367320e7fdeffbf511904f398c 6d04dfc8966019b8b0977b2cb942351f13d2b178 7aa7d608112baf63a0b1278955f9619427373807]. 

Git no me permite progresar desde este punto. No entiendo esto. Sé que las diferentes twigs a menudo se fusionan (especialmente en el tree de Linus), y es probable que el error se haya introducido en una twig lateral, pero incluso si ese es el caso, creo que debería ser capaz de identificar el compromiso que introdujo el error, incluso si eso es una fusión, cometer. ¿Y cómo es que el error se ha solucionado entre los commit enumerados, mientras que todavía tengo el problema cuando construyo el último commit?

Esto se responde en profundidad en un file de documentation en el tree de fonts de Git . Básicamente, Git te está diciendo que, de acuerdo con tu caso de testing, el código en tu propia sucursal es incorrecto y henetworkingó esa incorrección antes de que se separara una twig principal. El error se corrigió en la twig de características. Mientras tanto:

¿Y cómo es que el error se ha solucionado entre los commit enumerados, mientras que todavía tengo el problema cuando construyo el último commit?

Hay dos razones obvias para que este sea el caso:

  1. La twig de características con la corrección no es parte de la última confirmación.
  2. El error podría haber sido reparado, luego reintroducido.

El Caso 2 probablemente sea más probable aquí, y la solución podría ser tan simple o complicada como "pensamos que esta otra característica W estaba list, luego decidimos que no era así y la revertimos en la twig característica / X, luego pusimos retrocedió porque ahora estaba listo ", y es la característica / W en sí la causa del error, de modo que el error desaparece en la function / X compromiso-intervalo durante el cual la característica / W se revierte.

(En algunos casos, un error es accidentalmente reparado y luego reintroducido accidentalmente. Esto es común en algorithms que tienen alguna propiedad inestable que nadie piensa que importa, que realmente resulta ser importante. Por ejemplo, algunos algorithms de orderamiento no son estables) no conserva el order de los elementos "iguales" en la list de elementos que se orderan, y otros sí. Si todas las keys de sorting son únicas, la estabilidad del género es irrelevante. Si su error está vinculado a un tipo no único keys, entonces quizás el error real sea que el género no es estable, o que la key está equivocada y el error no es lo que piensas que es).