On Mon, 3 Nov 2008, Miquel van Smoorenburg wrote: > > If at this point I do a 'git bisect good' I end up in a 2.6.26 > branch, which is good, but after a few bisects I end up at > a version before v2.6.26 (2.6.26-rc5) again, which should be > impossible right ? No, not at all. What is going on is that you are hitting commits that were not merged into 2.6.26 (so they are _not_ in the "good" part), but they were _developed_ before it. So the kernel Makefile says "v2.6.26-rc8" (not quite 2.6.26 yet), but that's because the version in the Makefile ends up being a linear explanation of what the nearest _earlier_ version was, but is not at all indicative of the much more complex non-linear development model. IOW, you have history that looks like - A -> B -> C-> \ / - D - And let's say that 'A' is v2.6.26-rc8, while 'B' is the final v2.6.26 release, and is your 'good', while 'C' is 2.6.27, and is your 'bad'. What does that make 'D' then? It is clearly potentially bad, because it is _not_ in the good set (it was merged after 2.6.26, and could very well be the source of your bug. But think about what 'Makefile' must contain in 'D'. The difference between linear history and non-linear history is very important, and "git bisect" very much is all about getting it right. It does't take a "linear" half-way point, it really does a _set_ operation, and it bisects the set of commits. And that set of commits is a DAG, not a linear series. > Anyway - at the end I end up with a 'good' version that is > 2.6.26-rc<something> which is kind of useless. I know that > version up to 2.6.26 are good ... Not at all. It's not "kind of useless", it's very important. > What am I doing wrong ? You're not doing anything wrong, you just didn't realize how non-linear development works. Linus -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
