Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754502AbZAKWfI (ORCPT ); Sun, 11 Jan 2009 17:35:08 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751747AbZAKWex (ORCPT ); Sun, 11 Jan 2009 17:34:53 -0500 Received: from iabervon.org ([66.92.72.58]:58885 "EHLO iabervon.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751517AbZAKWex (ORCPT ); Sun, 11 Jan 2009 17:34:53 -0500 Date: Sun, 11 Jan 2009 17:34:51 -0500 (EST) From: Daniel Barkalow To: Alexey Zaytsev cc: Linus Torvalds , Sam Ravnborg , Christian Borntraeger , Johannes Schindelin , git@vger.kernel.org, Linux Kernel Mailing List Subject: Re: current git kernel has strange problems during bisect In-Reply-To: Message-ID: References: <200901111602.53082.borntraeger@de.ibm.com> <200901111607.59054.borntraeger@de.ibm.com> <200901111620.03345.borntraeger@de.ibm.com> <20090111194258.GA4840@uranus.ravnborg.org> User-Agent: Alpine 1.00 (LNX 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2749 Lines: 75 On Mon, 12 Jan 2009, Alexey Zaytsev wrote: > On Sun, Jan 11, 2009 at 23:04, Linus Torvalds > wrote: > > > > > > On Sun, 11 Jan 2009, Sam Ravnborg wrote: > >> > >> The cost of moving this piece of history from one git tree to another > >> git tree is that we make it harder to debug the kernel for the advanced user > >> that knows how to do bisect. > >> > >> It is not like this history would be lost - one just had to look > >> somewhere else to find it. > >> > >> That may be a bad pain/benefit ratio - time will tell. > > > > Umm. No. > > > > Time is exactly what makes it useful. It will make all the downsides > > shrink, and the advantages stay. > > > >> There should be a way to avoid such pain when bisecting without > >> having to mark a semi-random (for the average person) commit as good. > > > > Well, you don't actually have to mark that semi-random one as good either. > > What you can do is to just mark anything that _only_ contains fs/btrfs as > > good. IOW, you don't have to know the magic number - you just have to be > > told that "oh, if you only have btrfs files, and you're not actively > > bisecting a btrfs bug, just do 'git bisect good' and continue". > > > > Yeah, you'll hit it a few times, but you don't even have to compile things > > or boot anything, so it's not actually going to be all that much slower > > than just knowing about the magic point either. > > But would not such bug avoid being bisected if you blindly > mark btrfs commits as good? > > v2.6.29 <-- bad > ... > ... > ... > btrfs stuff <-- mark as good > ... > the-real-bug > ... > v2.6.28 <-- good > > So you hit the btrfs commit, mark it as good, leaving the real bug below, > and the bisection continues, with both sides being actually bad. > > Am I missing something? Yes, there are no kernel bugs below the btrfs stuff, because there's no kernel at all below the btrfs stuff. The history is actually like: A -- B -- C -- D -- G / F -- E F and E are the btrfs stuff, while A-D and G are commit containing the kernel source (D and G also containing btrfs). Marking E as good cuts off F, but doesn't cut off anything at all on the top line. Of course, if you're actually debugging a problem with btrfs that you somehow know to have worked while btrfs was a separate module at so point, you would want to get into this history (and would build it as a separate module in order to do so). -Daniel *This .sig left intentionally blank* -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/