git-bisect(1) next after finding the commit

7 messages between Oct 2, 2026 and Oct 5, 2026, from Alejandro Colomar, Jeff King, Junio C Hamano.

Plain Markdown or JSON for tools and agents.

Alejandro ColomarOct 2, 2026, 21:49 UTC on lore

Hi!

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.

Have a lovely day! Alex

-- 
<https://www.alejandro-colomar.es>

Jeff KingOct 2, 2026, 22:11 UTC in reply to Alejandro Colomar on lore

Re: git-bisect(1) next after finding the commit

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

Show 6 quoted 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

Junio C HamanoOct 2, 2026, 22:32 UTC in reply to Jeff King on lore

Re: git-bisect(1) next after finding the commit

Jeff King <peff@peff.net> writes:

Show 14 quoted lines

> 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.

Alejandro ColomarOct 3, 2026, 05:59 UTC in reply to Jeff King on lore

Re: git-bisect(1) next after finding the commit

Hi Jeff,

Show 13 quoted lines

> Date: 2026-10-02 18:11:54-0400
> From: Jeff King <peff@peff.net>
>
> 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.

Thanks!  It works.

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

Show 5 quoted lines

> 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

Have a lovely day! Alex

-- 
<https://www.alejandro-colomar.es>

Alejandro ColomarOct 3, 2026, 06:03 UTC in reply to Junio C Hamano on lore

Re: git-bisect(1) next after finding the commit

Hi Junio,

Show 32 quoted lines

> Date: 2026-10-02 15:32:13-0700
> From: Junio C Hamano <gitster@pobox.com>
>
> Jeff King <peff@peff.net> 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.

Thanks for confirming!  It certainly works for me (I've tested it).

Show 22 quoted lines

> [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.

Indeed, this optimization is what surprised me. I expected it would move the HEAD as with every other git-bisect(1) step, but the last one didn't move it. I can live with it, FWIW, since bisect/bad contains all the information I need (and anyway, I will move the HEAD myself, so I don't need the HEAD in any specific position). It was just surprising.

:)

Have a lovely day! Alex

-- 
<https://www.alejandro-colomar.es>

Jeff KingOct 5, 2026, 03:23 UTC in reply to Alejandro Colomar on lore

Re: git-bisect(1) next after finding the commit

On Sat, Oct 03, 2026 at 07:59:43AM +0200, Alejandro Colomar wrote:

Show 7 quoted lines

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

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

-Peff

Alejandro ColomarOct 5, 2026, 12:37 UTC in reply to Jeff King on lore

Re: git-bisect(1) next after finding the commit

Hi Jeff,

Show 15 quoted lines

> Date: 2026-10-04 23:23:48-0400
> From: Jeff King <peff@peff.net>
>
> On Sat, Oct 03, 2026 at 07:59:43AM +0200, Alejandro Colomar wrote:
> 
> > > 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?
> 
> Yeah. Or even just "git rev-parse bisect/bad" (maybe with --verify if
> appropriate).

Oh, thanks!  I've changed the rev-list -1 calls to do rev-parse.

Have a lovely day! Alex

> -Peff

-- 
<https://www.alejandro-colomar.es>