Each _individual_ release will be entirely bisectable, since it's all git
trees, and at no point does anything collapse individual commits together
like -mm does.
HOWEVER.
Due to the way linux-next works, each individual release will be basically
unrelated to the previous one, so it gets a bit more exciting indeed when
you say "the last linux-next version worked for me, but the current one
does not".
Git can actually do this - you can make the previous (good) linux-next
version be one branch, and the not-directly-related next linux-next build
be another, and then "git bisect" will _technically_ work, but:
- it will not necessarily be as efficient (because the linux-next trees
will have re-done all the merges, so there will be new commits and
patterns in between them)
- but much more distressingly, if the individual git trees that got
merged into linux-next were also using rebasing etc, now even all the
*base* commits will be different, and saying that the old release was
good tells you almost nothing about the new release!
(The good news is that if only a couple of trees do that, the bisection
information from the other trees that don't do it will still be valid
and useful and help bisection)
- also, while it's very easy for somebody who knows and understands git
branches, it's technically still quite a bit more challenging than just
following a single tree that never rebases (ie mine) and just bisecting
within that one.
So yes, git bisect will work in linux-next, and the fundamental nature of
git-bisect will not change at all, but it's going to be a bit weaker
"between different versions" of linux-next than it would be for the normal
git tree that doesn't do the "merge different trees all over again" thing
that linux-next does.
Linus
--
