Joel Kaasinen <joel@xxxxxxxxxxxxxxx> writes: > On Tue, Sep 6, 2011 at 19:38, Junio C Hamano <gitster@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html