From: D. Ben Knoble Date: Sat, 03 Oct 2026 13:45:17 GMT Subject: Re: git-visualize(1) plumbing equivalent Message-ID: In-Reply-To: On Sat, Oct 3, 2026 at 6:13 AM Alejandro Colomar 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