From: Sean <seanlkml@sympatico.ca>
Date: Tue, 24 Jul 2007 13:40:17 GMT
Subject: Re: rfe: bisecting with a tristate
Message-ID: <20070724094017.d14688e5.seanlkml@sympatico.ca>
In-Reply-To: <Pine.LNX.4.64.0707241459460.18990@fbirervta.pbzchgretzou.qr>

On Tue, 24 Jul 2007 15:21:19 +0200 (CEST)
Jan Engelhardt <jengelh@computergmbh.de> wrote:


Hi Jan,

> I have an idea about handling commits that do not compile at 
> all in git-bisect.
> For example:
> 
> git bisect start
> git bisect bad v2.6.23-rc1
> # bad: [f695baf2df9e0413d3521661070103711545207a] Linux 2.6.23-rc1
> git bisect good v2.6.22
> # good: [098fd16f00005f665d3baa7e682d8cb3d7c0fe6f] Linux 2.6.22
> 
> Then 1f1c2881f673671539b25686df463518d69c4649 will be the next commit 
> git bisect hands out. Now let's assume this commit would not compile. 
> What would the user do? git-bisect good or git-bisect bad?

Check out the section "Avoiding to test a commit" in the git-bisect
man page; it addresses this issue.  Basically you just use git-reset
to pick a different nearby commit to compile, and then continue with
git bisect good/bad.

> 
> Assume a commit previous to 1f..49 caused an oops (but the user does not 
> know yet), and the user said 'good' on 1f..49 because he did not know 
> what to say (since it did not compile). Then bisect would go the wrong 
> way, marking all left to 1f..49 as good.
> 
> Ideally, there should be like "git bisect dunno-try-left" and "git 
> bisect dunno-try-right", which allow the user to skip checking 1f..49 
> and instead try the next commit left or right of 1f..49 (to either go to 
> a commit before the compile failure, or after it).
>

Sean