[lkml]   [2006]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: git pull on Linux/ACPI release tree

    On Tue, 10 Jan 2006, Kyle Moffett wrote:
    > On Jan 10, 2006, at 01:38, Martin Langhoff wrote:
    > >
    > > The more complex your tree structure is, the more the interactions are
    > > likely to be part of the problem. Is git-bisect not useful in this scenario?
    > IIRC git-bisect just does an outright linearization of the whole tree anyways,
    > which makes git-bisect work everywhere, even in the presence of difficult
    > cross-merges.

    It's not really a linearization - at no time does git-bisect _order_ the
    commits. After all, no linear order actually exists.

    Instead, it really cuts the tree up into successively smaller parts.

    Think of it as doing a binary search in a 2-dimensional surface - you
    can't linearize the plane, but you can decide to test first one half of
    the surface, and then depending on whether it was there, you can halve
    that surface etc..

    > On the other hand, if you are git-bisecting ACPI changes
    > (perhaps due to some ACPI breakage), and ACPI has 10 pulls from mainline, you
    > _also_ have to wade through the bisection of any other changes that occurred
    > in mainline, even if they're totally irrelevant.

    Yes. Although if you _know_ that the problem happened in a specific file
    or specific subdirectory, you can actually tell "git bisect" to only
    bother with changes to that file/directory/set-of-directories to speed up
    the search.

    IOW, if you absolutely know that it's ACPI-related, you can do something

    git bisect start drivers/acpi arch/i386/kernel/acpi

    to tell the bisect code that it should totally ignore anything that
    doesn't touch those two directories.

    However, if it turns out that you were wrong (and the ACPI breakage was
    brought on by something that changed something else), "git bisect" will
    just get confused and report the wrong commit, so this is really something
    you should be careful with (and verify the end result by checking that
    undoing that _particular_ commit really fixes things).

    And yes, "git bisect" _will_ work with bugs that depend on two branches of
    a merge: it will point to the merge commit itself as being the problem.
    Now, at that point you really are screwed, and you'll have to figure out
    why both branches work, but the combination of them do not.

    Maybe it's as simple as just a merge done wrong (bad manual fixups), but
    maybe it's a perfectly executed merge that just happens to have one branch
    changing the assumptions that the other branch depended on.

    Happily, that is not very common. I know people are using "git bisect",
    and I don't think anybody has ever reported it so far. It will happen
    eventually, but I'd actually expect it to be much more common that "git
    bisect" will hit other - worse - problems, like bugs that "come and go",
    and that a simple bisection simply cannot find because they aren't
    totally repeatable.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-11-18 23:46    [W:0.023 / U:50.660 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site