git-visualize(1) plumbing equivalent
7 messages between Oct 3, 2026 and Oct 3, 2026, from Alejandro Colomar, D. Ben Knoble, Kristoffer Haugsbakk.
Plain Markdown or JSON for tools and agents.
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>
Re: git-visualize(1) plumbing equivalent
On Sat, Oct 3, 2026 at 6:13 AM Alejandro Colomar <alx@kernel.org> wrote:
Show 13 quoted lines
>
> 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.
Show 26 quoted lines
> 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
Show 20 quoted lines
> 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. :)
Show 32 quoted lines
>
> > 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>
Re: git-visualize(1) plumbing equivalent
On Sat, Oct 3, 2026, at 15:45, D. Ben Knoble wrote:
Show 10 quoted lines
>[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
On Sat, Oct 3, 2026 at 11:27 AM Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com> wrote:
Show 17 quoted lines
>
> 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.
--
D. Ben Knoble
Re: git-visualize(1) plumbing equivalent
On Sat, Oct 3, 2026 at 11:13 AM Alejandro Colomar <alx@kernel.org> wrote:
Show 7 quoted lines
>
> 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:
Show 27 quoted lines
> > > 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
Show 43 quoted lines
> 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>