Re: current git kernel has strange problems during bisect

[Boaz Harrosh <bharrosh@panasas.com>]

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