0

I am using bisect to find the good commit which fix a S4 issue from upstream kernel codes. But I meet a confusing issue when I do like this :

git bisect  start
git bisect bad  v4.8-rc1
git bisect good v4.7

it will take 13 steps to finish the result .

but I found the bisect will choose some commits older than v4.7 tag , is it normal ?

In my opinion ,bisect should choose commits between v4.7 tag and v4.8-rc1 tag judging from time line .

alexbt
  • 16,415
  • 6
  • 78
  • 87
Perry_yuan
  • 1
  • 2
  • By "older than", do you mean "having an author-date older than the author-date of the v4.7 tag and/or its target commit"? – torek Aug 29 '16 at 04:14

1 Answers1

0

In my opinion ,bisect should choose commits between v4.7 tag and v4.8-rc1 tag judging from time line .

This is not exactly what bisect will do. bisect will choose all commits which are contained in the tag v4.8-rc1 and not contained in tag v4.7. This will differ if e.g. a branch is created from v4.6 and changes are committed to it before v4.7 is created - but the branch is not merged into v4.7. Especially in kernel development there might be a lot of changes which have been committed quite some time before they have been merged. The date of those commits will then be before v4.7, however their changes are not contained in v4.7.

It is important that bisect behaves this way and not based on the time as it is used to find the commit which introduced a problem. This can also happen with a commit created before the "good" version but not contained into it yet.

If you have an commit with you can check in which tags it is contained using git tag --contains <commit-hash>. Most probably the tag v4.7 will not be part of that list and this is the explanation why those commits are chosen by git bisect.

lucash
  • 1,982
  • 17
  • 25