0

I did the following on a random git repository:

git bisect start
git bisect good HEAD~100
git bisect bad // Should just point to the current HEAD, right?

I would have expected a range of 100 commits to be tested by git, however what I got was 1000 commits (10x more). I am guessing there has to be a simple explanation for this, but I can't seem to find anything.

Edit: maybe I was not clear enough. I got 1000 commits in the range to be tested with git bisect. That would equate to roughly 9-10 commits to be tested.

What would the cause of this be?

cgf
  • 3,369
  • 7
  • 45
  • 65
  • what does `git rev-list HEAD~100..HEAD | wc -l` give you ? Maybe it's from branches and merges. – Andrew C Oct 14 '14 at 18:10
  • That gives me 3306. I am even more confused. – cgf Oct 14 '14 at 18:14
  • Interesting. I'm afraid I don't know how exactly each commit reachable maps to which commits bisect considers, maybe somebody else who does know will chime in. – Andrew C Oct 14 '14 at 18:18
  • No worries, thanks for confusing me more though. :D – cgf Oct 14 '14 at 18:24
  • 1
    See https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html#_bisection_algorithm – torek Oct 14 '14 at 18:40

1 Answers1

0

This is a very insightful question.

The commits are not all, necessarily, part of the same branch/trunk. Bisect will follow the changesets as they are referenced, which may lead across multiple branches - in and out of merges. This will yield a larger number of commits than what you expect based on the current branch.

If you compare the results from git log -n100 with those from git reflog you will see this.

Thom Parkin
  • 346
  • 1
  • 9