Completely naive answer based on extremely limited testing:
The range of commits left to probe can be obtained with git bisect visualize
, and this can be crudely counted with git bisect visualize | wc -l
or what have you.
The message that was printed prior to getting into this state appears to be based roughly on half this amount, and taking the base 2 log of that half.
For instance, I'm now in a state whereby I was told this:
Bisecting: 10 revisions left to test after this (roughly 3 steps)
And in this state I have:
$ git bisect visualize --oneline | wc -l
21
I.e. the "10 revisions" actually means there are 21 commits in the suspected range. We are in the middle of that range, so about 10 lie in either direction. To get the 10, we calculate 21/2, rounded down. To get the "Roughly 3 left to test", we just take the base 2 log of 10, rounded down.
In my favorite scripting language (substitute yours):
$ txr -P '(let* ((count (length
(get-lines
(open-command "git bisect visualize --oneline"))))
(left (trunc count 2)))
`Bisecting: @left revisions left to test after this \
\ (roughly @(int-flo (log2 left)) steps)`)'
Bisecting: 10 revisions left to test after this (roughly 3 steps)
Some error handling is needed since the bisect
command will complain if you haven't reported at least one good and one bad commit. There are also corner cases, like avoiding log2 being applied to zero, if that can occur.
git bisect
"(man) in C continues, and involve git bisect visualize. (Merged by Junio C Hamano --gitster
-- in commit 0a4cb1f, 23 Sep 2021) – Uno