Re: [BUG] git bisect start fails when stale bisect data is left behind

[Christian Couder <chriscool@tuxfamily.org>]

On Tuesday 06 September 2011 18:38:55 Junio C Hamano wrote:
> Christian Couder <christian.couder@gmail.com> writes:
> >> How to reproduce:
> >> $ echo foo > .git/BISECT_START
> >> $ git bisect start HEAD HEAD^
> >> 
> >> Fails with "fatal: invalid reference:" on git 1.7.6.
> > 
> > Yeah, it looks like a very old behavior.
> > I'd suggest a simple improvement in the error message like this:
> > 
> > diff --git a/git-bisect.sh b/git-bisect.sh
> > index c21e33c..bd7155b 100755
> > --- a/git-bisect.sh
> > +++ b/git-bisect.sh
> > @@ -67,7 +67,8 @@ bisect_start() {
> > 
> >         then
> >         
> >                 # Reset to the rev from where we started.
> >                 start_head=$(cat "$GIT_DIR/BISECT_START")
> > 
> > -               git checkout "$start_head" -- || exit
> > +               git checkout "$start_head" -- ||
> > +               die "Could not checkout previous start point
> > '$start_head'. Try 'git bisect reset <branch>' first."
> 
> I do not necessarily think this is a bug to begin with --- the user had a
> bad state, and bisect stopped without doing further damage.

Yeah, in fact commit f3a186ffade15f793ea17713a10e10ec4f26ff11 (bisect: improve 
error message when branch checkout fails, Sat Apr 4, 2009) already improved 
the error message, but probably didn't go far enough.

> The real question is what the sensible suggestion/advice the new message
> should give. It would have to involve bisect reset in the end to get rid
> of the stale bisect state, but wouldn't the user potentially lose some
> other state if s/he blindly followed the die message's suggestion and ran
> "bisect reset"?

When using "git bisect start" with an existing $GIT_DIR/BISECT_START file, the 
next thing we do after checking out the previous head from the BISECT_START 
file is a call to "bisect_clean_state". So all the previous bisect state is 
discarded except the previous head that is in $start_head.

If checking out the previous head fails, that probably means that the previous 
head is bad because it has been deleted.

In this case running "git bisect reset <branch>" and then "git bisect start 
..." is ok because there is no valuable state lost compared to the situation 
where "git bisect start ..." succeeded in the first place.

Of course if checking out the previous head failed because the 
$GIT_DIR/BISECT_START file has been corrupted, then it might be better to fix 
the content of this file. But anyway if we are able to fix the content of the 
file, for example by putting "foobar" in it instead of the truncated "foo" that 
made the checkout fail, then running "git bisect reset foobar" and then "git 
bisect start ..." would probably do the trick too.

It wouldn't do the trick if the $GIT_DIR/BISECT_START file also needed a 
permission change or more free space on the disc or something like that. But 
in this case we will get an hopefully meaningful error message when running 
"git bisect reset foobar" or "git bisect start ..." and we would not lose 
information.

Thanks,
Christian.