Re: git bisect should return 1 when the first bad commit is found

[Jeff King <peff@peff.net>]

On Mon, Jun 24, 2019 at 09:16:13AM +0200, Christian Couder wrote:

> So you just need to parse stdout to detect that it found the first bad
> commit, and then you can use refs/bisect/bad.
>
> If the return code was used, how would you distinguish between a
> failure in the command (for example if you give bad information to
> `git bisect good` or `git bisect bad`) and the fact that it has not
> yet found the first bad commit? Anyway you would need to add some
> logic for that.

Right, thanks for reminding us of that ref. I did leave a suggestion
elsewhere in the thread that we might be able to avoid the exit-code
pitfalls by using a specific "result" ref.

> If it would be HEAD, it would mean that git bisect would potentially
> have to do one more checkout so that HEAD points to the first bad
> commit. This checkout would sometimes be useless, so it's more
> efficient to use something like refs/bisect/bad rather than HEAD.

I'm not too concerned with the cost of checking out a tree. After all,
we've just done a bunch of checkouts and probably some operations on the
tree itself. But I think there's a much more important reason my
suggestion may have problems.

Sometimes we _can't_ checkout another commit, because part of testing
the bisection may involve mucking with the working tree. For instance,
earlier today I was bisecting a case where git.git did not show the
breakage itself, but applying a debugging patch on top did. So I was
bisecting along the real history, adding new contents, testing, and then
cleaning up my changes before jumping to the next bisection candidate.

On the other hand, I have to clean them up anyway before running "git
bisect good" or it cannot jump to the next candidate when we are not
finished. Jumping to "bad" when we _are_ finished is no different there.
But I think it does show that there can be surprising implications to
moving HEAD around.

-Peff