Re: git pull on Linux/ACPI release tree

[Linus Torvalds <torvalds@osdl.org>]

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