[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <496A1EF3.20204@panasas.com>
Date: Sun, 11 Jan 2009 18:31:47 +0200
From: Boaz Harrosh <bharrosh@...asas.com>
To: Christian Borntraeger <borntraeger@...ibm.com>
CC: Johannes Schindelin <Johannes.Schindelin@....de>,
git@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
torvalds@...ux-foundation.org
Subject: Re: current git kernel has strange problems during bisect
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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists