Properly detect ending conditions
Properly detect ending conditions

Sometimes, depending on the number of commits we're bisecting and
the number of workers, we can end up in a situation in which we
have a single commit left to test.  The old git-rev-list invocation
included the current bad revision, which meant that we always saw
two commits in the bisect range for this situation, and the selection
algorithm happens to choose the first one.  Since git-rev-list lists
commits in reverse order by default, this is always the bad commit,
so we never give git-bisect any new information and it never stops.

The other part of this patch is ignoring bisect_steps - it's the number
of steps we'll likely need to take *after* this round is complete, so
it's not an accurate indicator of whether or not we're done.

hoelzro/git-pisect