git bisect "commits left" miscount

[Ben Boeckel <mathstuf@xxxxxxxxx>]

Hi,

When bisecting given a set of paths, git counts the number of remaining
commits improperly. Here's example output (based in the git.git
repository):

    % git bisect start -- sha1_file.c
    % git bisect good v2.10.0
    % git bisect bad v2.10.3
    Bisecting: 1 revision left to test after this (roughly 1 step)
    [f7f0a87e0a27a1baaf782af7cec18fd23fdf35de] Merge branch 'jc/verify-loose-object-header' into maint
    % git bisect good
    Bisecting: 0 revisions left to test after this (roughly 0 steps)
    [5827a03545663f6d6b491a35edb313900608568b] fetch: use "quick" has_sha1_file for tag following
    % git bisect good
    Bisecting: -1 revisions left to test after this (roughly 0 steps)
    [39000e849970a554a257577dcb2fb844a523a1d1] Merge branch 'jk/fetch-quick-tag-following' into maint
    % git bisect good
    No testable commit found.
    Maybe you started with bad path parameters?

Note that it ends up with -1 revisions left and it doesn't end up with a
"this commit is the first bad commit" message.

Should git find the newest ancestors(s) of the given bad commit which
modifies the given paths and start counting from there?

I haven't bisected to find out when this was introduced yet (first seen
with 2.9.4; confirmed with 2.14.0-rc1).

Thanks,

--Ben