[lkml]   [2009]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: current git kernel has strange problems during bisect

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_

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.


 \ /
  Last update: 2009-01-11 20:17    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site