# git-bisect(1) next after finding the commit 7 messages from 2026-10-02 to 2026-10-05. Participants: Alejandro Colomar, Jeff King, Junio C Hamano. Thread: https://gitlist.dev/t/66451 ## Alejandro Colomar, 2026-10-02 21:49 Subject: git-bisect(1) next after finding the commit Message-ID: ``` 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 -- ``` ## Jeff King, 2026-10-02 22:11 Subject: Re: git-bisect(1) next after finding the commit Message-ID: <20261002221154.GA833115@coredump.intra.peff.net> In-Reply-To: ``` 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. -Peff ``` ## Junio C Hamano, 2026-10-02 22:32 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. ``` ## Alejandro Colomar, 2026-10-03 05:59 Subject: Re: git-bisect(1) next after finding the commit Message-ID: In-Reply-To: <20261002221154.GA833115@coredump.intra.peff.net> ``` Hi Jeff, > Date: 2026-10-02 18:11:54-0400 > From: Jeff King > > 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? > 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 -- ``` ## Alejandro Colomar, 2026-10-03 06:03 Subject: Re: git-bisect(1) next after finding the commit Message-ID: In-Reply-To: ``` Hi Junio, > Date: 2026-10-02 15:32:13-0700 > From: Junio C Hamano > > 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. Thanks for confirming! It certainly works for me (I've tested it). > [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 -- ``` ## Jeff King, 2026-10-05 03:23 Subject: Re: git-bisect(1) next after finding the commit Message-ID: <20261005032348.GA10163@coredump.intra.peff.net> In-Reply-To: ``` 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). -Peff ``` ## Alejandro Colomar, 2026-10-05 12:37 Subject: Re: git-bisect(1) next after finding the commit Message-ID: In-Reply-To: <20261005032348.GA10163@coredump.intra.peff.net> ``` Hi Jeff, > Date: 2026-10-04 23:23:48-0400 > From: Jeff King > > 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 -- ```