Taking a bisect log is repeatable, but pointless.
If you made any mistakes in bisecting (marking a kernel that was good as
being bad, or the other way around), the log will always replay to the
same thing, but it will still be wrong.
In other words, "git bisect" is only as reliable as the data you feed it,
and if the behavior isn't 100% repeatable and unambiguous (or if you
simply made a mistake), you need to double-check things.
So after bisecting a commit, if there is any question what-so-ever whether
the commit makes sense as a result, you need to double-check it. The best
way to double-check it is to go back to a known-bad state (preferably the
tip of the branch) and revert the presumed-bad commit, and verify that it
really fixes the behavior.
But if that is impossible (for example, because the commit no longer
reverts cleanly), at least make 100% sure that the state at the commit is
bad, and then go to (all) parents of that commit and make 100% sure that
the state at those points is _good_.
IOW, if you've pinpointed 71c11fb57b924c160297ccd9e1761db598d00ac2 as
being bad, then you should go back and double-check that its parent
(in this case 4607816f608b42a5379aca97ceed08378804c99f) is good.
Because if it's parent is also bad, then that just means that you made
some mistake in "git bisect".
The thing about bisecting is that it is _extremely_ efficient. It takes
essentially the minimal number of answers to get to the end result. But
that very efficiency also means that getting even just _one_ of those
answers wrong will take you _way_ off base. There's no room for error,
because bisect will take each bit and use it to maximally split the error
space.
In this case, it really sounds like maybe you marked the parent good, even
though you should have marked it bad.
Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
