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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
