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

From: Jeff King <peff@peff.net>
Date: Jun 25, 2019, 04:58 UTC
Message-ID: <20190625045848.GA7571@sigill.intra.peff.net>
In-Reply-To: <CAP8UFD1gWnkJZSzjOxOHdS4R3GCUSDgC9X85y_Yvc0LmyK19Cw@mail.gmail.com>

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

Show 8 quoted lines

> 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