Search code examples
gitgit-bisect

How do I get the current "status" of a git bisect?


I am making some personal modifications to oh-my-git (shows the git status on the terminal) and I would like to display the "status" of the current bisect. Specifically, I want to get the number of remaining commits and approximate number of steps that are a result of the last bisect command, e.g.:

Bisecting: 9 revisions left to test after this (roughly 3 steps)

It seems that the only way to obtain this information is by actually executing git bisect good or git bisect bad. However, I do not want to change the state of the repo by running either of these commands - I just want to obtain the current bisect state.


Solution

  • 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.