todas,
Estoy usando git bisect para encontrar un compromiso incorrecto para la falla de arranque de Linux.
Y el compromiso malo conocido actual es:
commit 0f3f4fef3520fe888303886b62224bac7a837cac Author: Darren Hart <dvhart@linux.intel.com> Date: Mon Mar 2 09:06:39 2015 -0800 Add manifest for 2015-03-02 El buen compromiso conocido es:
commit 857a433072364883be5e4a7e30b895360999c8ab Merge: d6182fe 0e28b83 Author: Darren Hart <dvhart@linux.intel.com> Date: Mon Feb 23 17:11:35 2015 -0800 Merge commit '0e28b83bcbf60b2485f55ec71ce540f9153725d4'
Por lo tanto escribo:
[root@localhost linux]# git bisect start [root@localhost linux]# [root@localhost linux]# git bisect good 857a433072364883be5e4a7e30b895360999c8ab [root@localhost linux]# git bisect bad 0f3f4fef3520fe888303886b62224bac7a837cac Bisecting: a merge base must be tested [c517d838eb7d07bbe9507871fab3931deccff539] Linux 4.0-rc1
Y el ID de confirmación de testing está en:
[root@localhost linux]# git log commit c517d838eb7d07bbe9507871fab3931deccff539 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Sun Feb 22 18:21:14 2015 -0800 Linux 4.0-rc1
que está por delante de la buena comisión:
commit 857a433072364883be5e4a7e30b895360999c8ab Date: Mon Feb 23 17:11:35 2015 -0800
Creo que bisect nunca encontrará el mal compromiso.
¿Extraño algo?
Gracias
Creo que tengo la respuesta, es causada por git rebase:
Supongamos que existe el siguiente historial y la twig actual es "tema":
A---B---C topic / D---E---F---G master
A partir de este punto, el resultado del siguiente command:
git rebase master
sería:
A'--B'--C' topic / D---E---F---G master
Entonces, B desapareció. Si B es una buena confirmación, y después de rebase, encontramos que C 'es una mala confirmación, el siguiente command:
git bisect start git bisect good B git bisect bad C'
generaría una confirmación de testing antes de B, por ejemplo: E.