1

When I run:

git bisect start <bad_commit> <good_commit>

I get:

Bisecting: 9727 revisions left to test after this (roughly 13 steps)

But the bad_commit and good_commit I specified are clearly only around 50 commits back in history. I did a "git log" and saw both of the commits there. I also verified the bad commit is more recent than the good commit.

What's going on here?

Chuque
  • 587
  • 1
  • 5
  • 22
  • 2
    This usually indicates that some branch(es) were merged. The bisect code will attempt to find the bad commit down each such side branch. The good news is that log2(10000) means you'll still only have to test roughly 13 to 14 commits. – torek Mar 16 '22 at 07:08
  • 2
    Also I think bisect takes rev-list args, you can add `--first-parent` to just find the merge that brought the bug. – jthill Mar 16 '22 at 09:51
  • @jthill yes thanks this solved my problem, a giant merge had gone in and caused this. If you add this as an answer I'll accept it – Chuque Mar 16 '22 at 18:40

1 Answers1

3

If you merged in a long-lived branch bisect by default will hunt through the whole branch. Easy way to wall off the side histories is to add --first-parent, that'll tell you the merge that brought the bug.

jthill
  • 55,082
  • 5
  • 77
  • 137