Re: [BUG] git bisect start fails when stale bisect data is left behind
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 7, 2011, 10:51 UTC
- Message-ID
- <7vaaag62xh.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <CAC6WLetO-KKkHmPHJ64rt6+BMbhUHUtNfxF3GK4obMUAuE9XXQ@mail.gmail.com>
Joel Kaasinen <joel@zenrobotics.com> writes:
Show 25 quoted lines
> On Tue, Sep 6, 2011 at 19:38, Junio C Hamano <gitster@pobox.com> wrote: >> 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. > > Oh, actually my git-bisect man page says: > > """ > Bisect reset > After a bisect session, to clean up the bisection state and return to > the original HEAD, issue the following command: > > $ git bisect reset > > By default, this will return your tree to the commit that was checked > out before git bisect start. (A new git bisect start will also do that, > as it cleans up the old bisection state.) > """ > > The parenthetical sentence seems to imply that a bisect start cleans > out the old state. The problem is that the cleaning fails when the > state is bad. (Try e.g. "git bisect start; git bisect start a b" where > a and b are valid refs.) > > It's pretty much the same to me how this gets resolved. I'm fine with > a more verbose error message from bisect start.
I do not think anybody minds "a more verbose" message. I do mind if the suggestion the message makes were "wrong". That is what I was questioning.