From: Christian Couder <chriscool@tuxfamily.org>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Subject: Re: current git kernel has strange problems during bisect
Date: Mon, 12 Jan 2009 06:03:03 +0100
User-Agent: KMail/1.9.9
Cc: Pierre Habouzit <madcoder@debian.org>,
       Alexey Zaytsev <alexey.zaytsev@gmail.com>,
       Sam Ravnborg <sam@ravnborg.org>,
       Linus Torvalds <torvalds@linux-foundation.org>,
       Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
References: <200901111602.53082.borntraeger@de.ibm.com> <20090111230240.GA27489@artemis.corp> <200901120551.56791.chriscool@tuxfamily.org>
In-Reply-To: <200901120551.56791.chriscool@tuxfamily.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200901120603.03977.chriscool@tuxfamily.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 825
Lines: 19

I wrote:
>
> Anyway it looks to me that this kind of problem could be avoided if one
> could "replace" some commits only when bisecting. In this case what could
> be done is that one could "replace" the commit where btrfs is merged with
> one commit that cuts off the btrfs history.

By the way, it possible right now to cut off the btrfs history in one's own 
repository using a graft. One don't need to wait for me to finish the 
replace stuff I am slowly working on. But on the other hand it will have 
all the restrictions of the current graft mechanism.

Regards,
Christian.
--
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/