Re: git pull on Linux/ACPI release tree

From: Linus Torvalds <torvalds@osdl.org>
Date: Jan 10, 2006, 18:27 UTC
Message-ID: <Pine.LNX.4.64.0601101015260.4939@g5.osdl.org>
In-Reply-To: <252A408D-0B42-49F3-92BC-B80F94F19F40@mac.com>

On Tue, 10 Jan 2006, Kyle Moffett wrote:

Show 9 quoted lines

>
> 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