Re: current git kernel has strange problems during bisect

From: Boaz Harrosh <bharrosh@panasas.com>
Date: Jan 11, 2009, 16:31 UTC
Message-ID: <496A1EF3.20204@panasas.com>
In-Reply-To: <200901111620.03345.borntraeger@de.ibm.com>

Christian Borntraeger wrote:

Show 24 quoted lines

> 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