Because of branches and merges there isn't necessarily a single "next" or "previous" commit even when you are "between" commits A
and B
:
o - o - o
/ \
... - A - * - o o - B
\ /
o ------ o
If you are on node *
there is an obvious next/previous commit, the next is the rightward node o
and the previous is node A
. But after you move forward one, what's the next "next" commit? Should we traverse upwards to the three-node line, or downwards to the two-node line?
git bisect
does a lot of tricky stuff to minimize the number of nodes tested while also handling (or trying to handle) these branch-and-merge cases.
Mayvbe you are not looking to test some binary condition. For instance, suppose your static analysis tool is simply generating a bunch of metrics and you want to find out, e.g., that "every N commits / minutes / hours / days, metric A tends to go up somewhat while metric B tends to go down, but during this particular period the trend reversed." In this case you will need to define your own metric for "every N commits" or "every N hours" or whatnot, probably by running git rev-list
and working with raw commit IDs from then on.
In general, git rev-list
is the tool that handles this, and in fact, git bisect
itself uses git rev-list
with --bisect
(see the documentation for details; note that it stores names in the refs/bisect
name space so that it can be used iteratively). The rev-list command has several additional bisect variants that you may find useful.