git-visualize(1) plumbing equivalent

git-visualize(1) plumbing equivalent

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]

Hi!

I have this code, which I use to loop in a script using git-bisect(1):

	while
		git bisect visualize --oneline \
		| wc -l \
		| xargs -I{} test {} -gt 1;
	do
		if
			git rebase $gropts BISECT_HEAD >/dev/null 2>/dev/null;
			test $? -eq 0;
		then
			echo 'Rebase: success';
			git bisect good BISECT_HEAD;
		else
			echo 'Rebase: conflict';
			git rebase --abort >/dev/null;
			git bisect bad BISECT_HEAD;
		fi;
	done;

(
I know this resembles "git rebase run", but I'm avoiding it, because
passing all of that as a command is non-trivial (and I'd like to avoid
having to write a separate script to pass its name to "git bisect run").
)

Having read the documentation for git-bisect(1), visualize reads several
environment variables, and thus this code doesn't seem robust.  What
would be the plumbing version of the while-loop condition?

		git bisect visualize --oneline \
		| wc -l \
		| xargs -I{} test {} -gt 1;

The goal is to know whether git-bisect(1) has found a commit yet or not,
to stop looping.


Have a lovely day!
Alex

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: git-visualize(1) plumbing equivalent

[D. Ben Knoble]

On Sat, Oct 3, 2026 at 6:13 AM Alejandro Colomar <alx@kernel.org> wrote:
>
> Hi!
>
> I have this code, which I use to loop in a script using git-bisect(1):
>
>         while
>                 git bisect visualize --oneline \
>                 | wc -l \
>                 | xargs -I{} test {} -gt 1;
>         do
>                 if
>                         git rebase $gropts BISECT_HEAD >/dev/null 2>/dev/null;
>                         test $? -eq 0;

Aside: this "test $? -eq 0" is a bit redundant, no? "if cmd" in shell
works by checking whether "cmd" exits 0 or not.

>                 then
>                         echo 'Rebase: success';
>                         git bisect good BISECT_HEAD;
>                 else
>                         echo 'Rebase: conflict';
>                         git rebase --abort >/dev/null;
>                         git bisect bad BISECT_HEAD;
>                 fi;
>         done;
>
> (
> I know this resembles "git rebase run", but I'm avoiding it, because
> passing all of that as a command is non-trivial (and I'd like to avoid
> having to write a separate script to pass its name to "git bisect run").
> )
>
> Having read the documentation for git-bisect(1), visualize reads several
> environment variables, and thus this code doesn't seem robust.  What
> would be the plumbing version of the while-loop condition?
>
>                 git bisect visualize --oneline \
>                 | wc -l \
>                 | xargs -I{} test {} -gt 1;
>
> The goal is to know whether git-bisect(1) has found a commit yet or not,
> to stop looping.

I think you are probably looking for the (size of the) set of commits
between bisect/bad and all the bisect/good-* refs. So you might need
to "git refs list" the good ones, and feed those as negated refs
alongside bisect/bad to rev-list?

In the general case, that wouldn't account for skipped commits as I
understand it, where multiple commits are left at the end of the
bisect, but in your script it doesn't look like you skip any.

-- 
D. Ben Knoble

Re: git-visualize(1) plumbing equivalent

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2792 bytes --]

Hi Ben,

> Date: 2026-10-03 09:45:17-0400
> From: "D. Ben Knoble" <ben.knoble@gmail.com>
>
> On Sat, Oct 3, 2026 at 6:13 AM Alejandro Colomar <alx@kernel.org> wrote:
> >
> > Hi!
> >
> > I have this code, which I use to loop in a script using git-bisect(1):
> >
> >         while
> >                 git bisect visualize --oneline \
> >                 | wc -l \
> >                 | xargs -I{} test {} -gt 1;
> >         do
> >                 if
> >                         git rebase $gropts BISECT_HEAD >/dev/null 2>/dev/null;
> >                         test $? -eq 0;
> 
> Aside: this "test $? -eq 0" is a bit redundant, no? "if cmd" in shell
> works by checking whether "cmd" exits 0 or not.

Ouch!  Indeed.  IIRC, I originally had the test reversed (-ne 0), and
later probably flipped without thinking it could be removed.  :)

> 
> >                 then
> >                         echo 'Rebase: success';
> >                         git bisect good BISECT_HEAD;
> >                 else
> >                         echo 'Rebase: conflict';
> >                         git rebase --abort >/dev/null;
> >                         git bisect bad BISECT_HEAD;
> >                 fi;
> >         done;
> >
> > (
> > I know this resembles "git rebase run", but I'm avoiding it, because
> > passing all of that as a command is non-trivial (and I'd like to avoid
> > having to write a separate script to pass its name to "git bisect run").
> > )
> >
> > Having read the documentation for git-bisect(1), visualize reads several
> > environment variables, and thus this code doesn't seem robust.  What
> > would be the plumbing version of the while-loop condition?
> >
> >                 git bisect visualize --oneline \
> >                 | wc -l \
> >                 | xargs -I{} test {} -gt 1;
> >
> > The goal is to know whether git-bisect(1) has found a commit yet or not,
> > to stop looping.
> 
> I think you are probably looking for the (size of the) set of commits
> between bisect/bad and all the bisect/good-* refs. So you might need
> to "git refs list" the good ones, and feed those as negated refs
> alongside bisect/bad to rev-list?

Yup, this seems to work:

git refs list | grep refs/bisect/ | sed '/good/s/^/^/' | cut -f1 -d' ' | xargs git rev-list 

> 
> In the general case, that wouldn't account for skipped commits as I
> understand it, where multiple commits are left at the end of the
> bisect, but in your script it doesn't look like you skip any.

Hmmmm.  I'm now working on adding the ability to skip commits, so this
would be a problem.  Do you have any idea on how to deal with that?


Have a lovely day!
Alex

> 
> -- 
> D. Ben Knoble

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: git-visualize(1) plumbing equivalent

[D. Ben Knoble]

On Sat, Oct 3, 2026 at 11:13 AM Alejandro Colomar <alx@kernel.org> wrote:
>
> Hi Ben,
>
> > Date: 2026-10-03 09:45:17-0400
> > From: "D. Ben Knoble" <ben.knoble@gmail.com>
> >
> > On Sat, Oct 3, 2026 at 6:13 AM Alejandro Colomar <alx@kernel.org> wrote:

[snip]

> > > Having read the documentation for git-bisect(1), visualize reads several
> > > environment variables, and thus this code doesn't seem robust.  What
> > > would be the plumbing version of the while-loop condition?
> > >
> > >                 git bisect visualize --oneline \
> > >                 | wc -l \
> > >                 | xargs -I{} test {} -gt 1;
> > >
> > > The goal is to know whether git-bisect(1) has found a commit yet or not,
> > > to stop looping.
> >
> > I think you are probably looking for the (size of the) set of commits
> > between bisect/bad and all the bisect/good-* refs. So you might need
> > to "git refs list" the good ones, and feed those as negated refs
> > alongside bisect/bad to rev-list?
>
> Yup, this seems to work:
>
> git refs list | grep refs/bisect/ | sed '/good/s/^/^/' | cut -f1 -d' ' | xargs git rev-list
>
> >
> > In the general case, that wouldn't account for skipped commits as I
> > understand it, where multiple commits are left at the end of the
> > bisect, but in your script it doesn't look like you skip any.
>
> Hmmmm.  I'm now working on adding the ability to skip commits, so this
> would be a problem.  Do you have any idea on how to deal with that?

Not offhand, sorry :/ I'm not totally sure how bisect represents that state.

-- 
D. Ben Knoble

Re: git-visualize(1) plumbing equivalent

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]

Hi Ben,

> Date: 2026-10-03 13:10:43-0400
> From: "D. Ben Knoble" <ben.knoble@gmail.com>
>
> On Sat, Oct 3, 2026 at 11:13 AM Alejandro Colomar <alx@kernel.org> wrote:
> >
> > Hi Ben,
> >
> > > Date: 2026-10-03 09:45:17-0400
> > > From: "D. Ben Knoble" <ben.knoble@gmail.com>
> > >
> > > On Sat, Oct 3, 2026 at 6:13 AM Alejandro Colomar <alx@kernel.org> wrote:
> 
> [snip]
> 
> > > > Having read the documentation for git-bisect(1), visualize reads several
> > > > environment variables, and thus this code doesn't seem robust.  What
> > > > would be the plumbing version of the while-loop condition?
> > > >
> > > >                 git bisect visualize --oneline \
> > > >                 | wc -l \
> > > >                 | xargs -I{} test {} -gt 1;
> > > >
> > > > The goal is to know whether git-bisect(1) has found a commit yet or not,
> > > > to stop looping.
> > >
> > > I think you are probably looking for the (size of the) set of commits
> > > between bisect/bad and all the bisect/good-* refs. So you might need
> > > to "git refs list" the good ones, and feed those as negated refs
> > > alongside bisect/bad to rev-list?
> >
> > Yup, this seems to work:
> >
> > git refs list | grep refs/bisect/ | sed '/good/s/^/^/' | cut -f1 -d' ' | xargs git rev-list
> >
> > >
> > > In the general case, that wouldn't account for skipped commits as I
> > > understand it, where multiple commits are left at the end of the
> > > bisect, but in your script it doesn't look like you skip any.
> >
> > Hmmmm.  I'm now working on adding the ability to skip commits, so this
> > would be a problem.  Do you have any idea on how to deal with that?
> 
> Not offhand, sorry :/ I'm not totally sure how bisect represents that state.

Thanks anyway!  I think this is getting hard enough, that it might be
worth piping a heredocument into a mktemp(1) file within the script, and
passing that to 'git bisect run'.


Cheers,
Alex

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: git-visualize(1) plumbing equivalent

[Kristoffer Haugsbakk]

On Sat, Oct 3, 2026, at 15:45, D. Ben Knoble wrote:
>[snip]
> On Sat, Oct 3, 2026 at 6:13 AM Alejandro Colomar <alx@kernel.org> wrote:
>>[snip]
>> The goal is to know whether git-bisect(1) has found a commit yet or not,
>> to stop looping.
>
> I think you are probably looking for the (size of the) set of commits
> between bisect/bad and all the bisect/good-* refs. So you might need
> to "git refs list" the good ones, and feed those as negated refs
> alongside bisect/bad to rev-list?

I think you can do that directly with `git rev-list --bisect` and the
other variants that start with `--bisect-`.

I have never used them myself.

>
> In the general case, that wouldn't account for skipped commits as I
> understand it, where multiple commits are left at the end of the
> bisect, but in your script it doesn't look like you skip any.

Re: git-visualize(1) plumbing equivalent

[D. Ben Knoble]

On Sat, Oct 3, 2026 at 11:27 AM Kristoffer Haugsbakk
<kristofferhaugsbakk@fastmail.com> wrote:
>
> On Sat, Oct 3, 2026, at 15:45, D. Ben Knoble wrote:
> >[snip]
> > On Sat, Oct 3, 2026 at 6:13 AM Alejandro Colomar <alx@kernel.org> wrote:
> >>[snip]
> >> The goal is to know whether git-bisect(1) has found a commit yet or not,
> >> to stop looping.
> >
> > I think you are probably looking for the (size of the) set of commits
> > between bisect/bad and all the bisect/good-* refs. So you might need
> > to "git refs list" the good ones, and feed those as negated refs
> > alongside bisect/bad to rev-list?
>
> I think you can do that directly with `git rev-list --bisect` and the
> other variants that start with `--bisect-`.
>
> I have never used them myself.

Thanks, TIL.

-- 
D. Ben Knoble