Re: rfe: bisecting with a tristate

[Sean <seanlkml@sympatico.ca>]

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