From: Brian Gernhardt <benji@silverinsanity.com>
Date: Thu, 08 Nov 2007 18:38:03 GMT
Subject: Re: [PATCH v2] user-manual: add advanced topic "bisecting merges"
Message-ID: <DE41BBF5-DD69-4A6B-97EE-ED42C8B1B616@silverinsanity.com>
In-Reply-To: <5498B368-053A-424E-B901-A55B66FF5801@lrde.epita.fr>


On Nov 8, 2007, at 9:51 AM, Benoit Sigoure wrote:

> You're missing the point.  Johannes suggested that you rebase *only*  
> for bisecting purpose.  Once you find the culprit commit, throw away  
> your rebased stuff.  I've never thought about doing this myself, but  
> it's a very clever way of tackling this problem.  It's slightly less  
> convenient if you need to bisect a large portion of the history  
> (that involves many branches and merges) because in this case we'd  
> like to have a magic git-linearize-history <start-treeish> <end- 
> treeish>.  Unless this is already easily doable with git-rebase?


I don't think you have to linearize it before bisecting.  If you  
bisect and discover that it was due to a merge, then you can rebase  
*that merge* to discover what part of the merge caused the issue.

~~ Brian