Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

Tags:

git

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.

like image 281
Compholio Avatar asked Jun 06 '16 21:06

Compholio


People also ask

What information does git status show?

The git status command displays the state of the working directory and the staging area. It lets you see which changes have been staged, which haven't, and which files aren't being tracked by Git. Status output does not show you any information regarding the committed project history.

How do you use git bisect to find the commit?

You use it by first telling it a "bad" commit that is known to contain the bug, and a "good" commit that is known to be before the bug was introduced. Then git bisect picks a commit between those two endpoints and asks you whether the selected commit is "good" or "bad".

How do you reset a bisect?

Bisect reset (A new git bisect start will also do that, as it cleans up the old bisection state.) For example, git bisect reset HEAD will leave you on the current bisection commit and avoid switching commits at all, while git bisect reset bisect/bad will check out the first bad revision.


1 Answers

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.

like image 149
Kaz Avatar answered Oct 13 '22 09:10

Kaz