From: Junio C Hamano Date: Fri, 02 Oct 2026 22:32:13 GMT Subject: Re: git-bisect(1) next after finding the commit Message-ID: In-Reply-To: <20261002221154.GA833115@coredump.intra.peff.net> Jeff King writes: > On Fri, Oct 02, 2026 at 11:49:01PM +0200, Alejandro Colomar wrote: > >> Is there a plumbing command for retrieving the bisected commit after >> a git-bisect(1) session has successfully found it (and of course before >> resetting the session)? >> >> I expected `git bisect next` would bring me to it, and then I'd rev-list >> HEAD -1, but it doesn't bring me to it. > > I'm not 100% sure, but I think "git show bisect/bad" should work. > > As the bisection progresses, we advance a single refs/bisect/bad from > the bottom of the range (the top is multiple refs/bisect/good-* refs). > So at the end, it should point to the blamed commit. The only code that gives "is the first .* commit" message is this bit in bisect.c: if (oideq(bisect_rev, current_bad_oid)) { res = error_if_skipped_commits(tried, current_bad_oid); if (res) goto cleanup; printf("%s is the first '%s' commit\n", oid_to_hex(bisect_rev), term_bad); it is fed bisect_rev only when it is the same as current_bad_oid, which was read from "refs/bisect/bad". So I think you are right. [Footnote] There is a last-step optimization that made me double check the code, but the optimization is about not bothering to move HEAD and not moving refs/bisect/bad pointer. We have a three-topic branch X, X is at the tip, X~1 at the middle and X-2 at the bottom. X~3 is on the mainline. ----- X~3 ---- X~2 ---- X~1 ---- X We found X~2 to be good. X is bad. $ git bisect start X X~2 We are asked to test X~1. * It turns out to be bad. We move bisect/bad to X~1. And then we report that X~1 is the first bad commit. * Or it turns out to be good. Then we report that X is the first bad commit. But we do not move HEAD and checkout X.