git-visualize(1) plumbing equivalent

DISCUSSION Alejandro Colomar 3 participants 7 messages Oct 3

lore

Share & tools

lore

Alejandro Colomar

author

2026-10-03 10:10 UTC #0 lore raw

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

Signature · 1 line

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

D. Ben Knoble

2026-10-03 13:45 UTC #1 lore raw

Quoted 5 lines · Alejandro Colomar

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

Quoted 8 lines

        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.

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

Quoted 6 lines

                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.

Signature · 1 line

D. Ben Knoble

Alejandro Colomar

author

2026-10-03 15:13 UTC #2 lore raw

Hi Ben,

Quoted 18 lines

Date: 2026-10-03 09:45:17-0400
From: "D. Ben Knoble" <[email protected]>
Quoted 5 lines · Alejandro Colomar
Hi!
I have this code, which I use to loop in a script using git-bisect(1):
Quoted 8 lines
        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;

Quoted 2 lines

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

Quoted 25 lines

Quoted 25 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;

Quoted 7 lines

Quoted 2 lines
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

Quoted 4 lines

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

Quoted 3 lines

Signature · 2 lines
-- 
D. Ben Knoble

Signature · 1 line

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

D. Ben Knoble

2026-10-03 17:10 UTC #3 lore raw

Quoted 7 lines · Alejandro Colomar

Hi Ben,
Quoted 4 lines
Date: 2026-10-03 09:45:17-0400
From: "D. Ben Knoble" <[email protected]>
On Sat, Oct 3, 2026 at 6:13 AM Alejandro Colomar <[email protected]> wrote:

[snip]

Quoted 21 lines

Quoted 8 lines
Quoted 8 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;
Quoted 7 lines
Quoted 2 lines
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
Quoted 1 line

Quoted 6 lines

Quoted 3 lines
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.

Signature · 1 line

D. Ben Knoble

Alejandro Colomar

author

2026-10-03 17:50 UTC #4 lore raw

Hi Ben,

Quoted 35 lines

Date: 2026-10-03 13:10:43-0400
From: "D. Ben Knoble" <[email protected]>
Quoted 7 lines · Alejandro Colomar
Hi Ben,
Quoted 4 lines
Date: 2026-10-03 09:45:17-0400
From: "D. Ben Knoble" <[email protected]>
On Sat, Oct 3, 2026 at 6:13 AM Alejandro Colomar <[email protected]> wrote:
[snip]
Quoted 21 lines
Quoted 8 lines
Quoted 8 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;
Quoted 7 lines
Quoted 2 lines
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
Quoted 1 line

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
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

Signature · 1 line

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

Kristoffer Haugsbakk

2026-10-03 15:27 UTC #5 lore raw

In reply to D. Ben Knoble

Quoted 10 lines · D. Ben Knoble

[snip]
Quoted 3 lines · Alejandro Colomar
[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.

Quoted 4 lines

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

2026-10-03 17:09 UTC #6 lore raw

Quoted 13 lines · Kristoffer Haugsbakk

Quoted 10 lines · D. Ben Knoble
[snip]
Quoted 3 lines · Alejandro Colomar
[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?

Quoted 4 lines

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.

Signature · 1 line

D. Ben Knoble