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
