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
