Re: rfe: bisecting with a tristate

From: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
Date: Jul 24, 2007, 17:07 UTC
Message-ID: <200707241907.57857.robin.rosenberg.lists@dewire.com>
In-Reply-To: <Pine.LNX.4.64.0707241447200.14781@racer.site>

tisdag 24 juli 2007 skrev Johannes Schindelin:

Show 20 quoted lines

> Hi,
> 
> On Tue, 24 Jul 2007, Sean wrote:
> 
> > > 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.
> 
> But a "git bisect dunno" would be handy.

Why? Not doing anything is enough, just select a new commit. Going back can be done by git reset, but forward (towards original HEAD) requires more thinking so a git bisect forward [n] would help there.

-- robin