From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: current git kernel has strange problems during bisect
Date: Sun, 11 Jan 2009 19:14:48 UTC
Message-ID: <fa.kQELjmR1Y5OG3fntU1diOsW1SUQ@ifi.uio.no>

On Sun, 11 Jan 2009, Christian Borntraeger wrote:
>
> I think we should really avoid merging subtrees to the linux kernel. It
> makes bisecting a real PITA. Furthermore, It is unlikely, but what if
> the problem is part of the 581 changesets from btrfs?

Umm, yes?

The thing is, btrfs was developed as an outside module. There are two
choices: import it with history, or import it without history. The history
is interesting, so importing _with_ it is a much nicer one. But that does
mean that btrfs introduces into the kernel tree the same behaviour we've
had in the git development tree for a long time - multiple root commits,
and "independent" branches that get merged.

It's actually very natural for git, and the btrfs tree actually was
re-done with "git filter-branch" to move all the history so that it is in
fs/btrfs, rather than moving around from the root like the _original_
development was done. So it's not technically a subtree merge, it's a
regular merge with just two different root commits - one for the original
base kernel development, one for the original btrfs kernel development.

For bisect, it's indeed somewhat annoying, and we could have perhaps done
some things a bit differently, but it's about the closest you can get to
"real history" without making the first btrfs merge-point a _total_
disaster.

For bisect purposes, if you know you're not chasing down a btrfs issue,
you can do

	git bisect good 34353029534a08e41cfb8be647d734b9ce9ebff8

where that commit 34353029 is the last one which has _just_ the btrfs
files. The next commit is when it does "Merge Btrfs into fs/btrfs", and
that one has the whole kernel tree again.

			Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: current git kernel has strange problems during bisect
Date: Sun, 11 Jan 2009 20:04:46 UTC
Message-ID: <fa.wOtu0g+8qUnYm28SRiYbK7Kif9E@ifi.uio.no>

On Sun, 11 Jan 2009, Sam Ravnborg wrote:
>
> The cost of moving this piece of history from one git tree to another
> git tree is that we make it harder to debug the kernel for the advanced user
> that knows how to do bisect.
>
> It is not like this history would be lost - one just had to look
> somewhere else to find it.
>
> That may be a bad pain/benefit ratio - time will tell.

Umm. No.

Time is exactly what makes it useful. It will make all the downsides
shrink, and the advantages stay.

> There should be a way to avoid such pain when bisecting without
> having to mark a semi-random (for the average person) commit as good.

Well, you don't actually have to mark that semi-random one as good either.
What you can do is to just mark anything that _only_ contains fs/btrfs as
good. IOW, you don't have to know the magic number - you just have to be
told that "oh, if you only have btrfs files, and you're not actively
bisecting a btrfs bug, just do 'git bisect good' and continue".

Yeah, you'll hit it a few times, but you don't even have to compile things
or boot anything, so it's not actually going to be all that much slower
than just knowing about the magic point either.

So now you can consider yourself told how to solve it. It wasn't that
hard. And the advantage is that we have real history.

			Linus