git-bisect(1) next after finding the commit

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.

Quoted 4 lines · Alejandro Colomar

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)?

Quoted 2 lines

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.

Date: 2026-10-02 15:32:13-0700
From: Junio C Hamano <[email protected]>

Quoted 6 lines · Jeff King

Quoted 4 lines · Alejandro Colomar

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)?

Quoted 8 lines

Quoted 2 lines

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.

Date: 2026-10-02 18:11:54-0400
From: Jeff King <[email protected]>

On Fri, Oct 02, 2026 at 11:49:01PM +0200, Alejandro Colomar wrote:

Quoted 6 lines

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.

-Peff

Quoted 1 line

I'm not 100% sure, but I think "git show bisect/bad" should work.

Thanks! It works.

I guess the plumbing version of it would be
git rev-list -1 bisect/bad
right?

Date: 2026-10-04 23:23:48-0400
From: Jeff King <[email protected]>

Quoted 2 lines · Alejandro Colomar

Quoted 1 line

I'm not 100% sure, but I think "git show bisect/bad" should work.

Quoted 5 lines

Thanks! It works.

I guess the plumbing version of it would be
git rev-list -1 bisect/bad
right?

Yeah. Or even just "git rev-parse bisect/bad" (maybe with --verify if appropriate).

-Peff