Christian Borntraeger wrote: > Am Sonntag 11 Januar 2009 schrieben Sie: >> Hi, >> >> On Sun, 11 Jan 2009, Christian Borntraeger wrote: >> >>> Am Sonntag 11 Januar 2009 schrieb Christian Borntraeger: >>>> doing a >>>> git bisect start >>>> git bisect good a3a798c >>>> git bisect bad v2.6.29-rc1 >>>> >>>> results in a repository without several files, e.g Makefile! >>>> git describe also fails. >>> In fact, retesting with a clean repository shows, that there are only > btrfs >>> files - nothing else. >>> >>> Linus did you pull a broken btrfs repository? >> I guess it is a subtree merge. So no, nothing went wrong >> >> Use "git bisect skip" to skip over those. > > I think we should really avoid merging subtrees to the linux kernel. It makes > bisecting a real PITA. Should is too soft, we cannot. What if it changes mainline files, they will not have common ancestry. And also the sub-tree checkout un-checkout will take ages. Chris must have merged with his subtree with a rebase not a merge. I suspect Linus git tree will have to rebase. This is the first time I've seen such a merge. for example see be0e5c097f it has no parent, and so on. > Furthermore, It is unlikely, but what if the problem is part of the 581 > changesets from btrfs? > Exactly > Christian > -- Boaz -- 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
