lkml.org 
[lkml]   [2009]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.29-rc8: Reported regressions from 2.6.28


    On Mon, 16 Mar 2009, Jeff Chua wrote:
    >
    > Take the attached bisect log and replay it

    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


    \
     
     \ /
      Last update: 2009-03-16 21:09    [W:0.023 / U:121.396 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site