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
like
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.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
