On Mon, Jun 24, 2019 at 11:41:53AM -0700, Junio C Hamano wrote: > > I think it might be nice for Git to write a well-known refname (like > > BISECT_RESULT or similar) so that you can refer to that instead of > > having to read stdout (whether by machine or by a user > > cutting-and-pasting). And I cannot offhand think of a particular reason > > why that could not just be HEAD (instead of something bisect-specific) > > after the bisect finishes. > > As Christian downthread reminds us, that is what the bisect/bad ref > is (which I totally forgot when I gave the earlier response). I do > not think we need a new ref, but I do not think it is so bad to add > an option "git bisect --exit-code ( --good | --bad ) [<commit-ish>]" > that makes the command usually exit with non-zero status. Unless we > have found the final answer successfully, that is, and in that case > the command would exit with 0 status to signall "all done". > > But that should be an option. Ah, right, I forgot that we already have such a ref. So that does seem like a reasonable way to access it (and as Christian notes, it's documented as well). And I agree with you that any exit-code magic should require the user to ask for it explicitly. I do think that accessing the bisect/bad ref is a little intimate with the implementation (i.e., it implies knowing that there is only a single "bad" that we are moving around, unlike "good", where we may mark many such tips). So another option is to put the result in a new ref (bisect/result, perhaps), but with one twist: delete it at the beginning of a bisection, so its presence can be used as a marker that the bisection is complete. I.e., you could do "git rev-parse --verify refs/bisect/result" as an alternative to "--exit-code". That gives you the added flexibility of asking "is the bisection done" separately from "do this next bisection step". -Peff
