Messages in this thread | | | Date | Wed, 30 Apr 2008 15:08:26 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Slow DOWN, please!!! |
| |
On Wed, 30 Apr 2008, Rafael J. Wysocki wrote: > > How bisectable is linux-next, BTW?
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
| |