On Fri, May 13, 2011 at 9:38 AM, Andrew Lutomirski <luto@xxxxxxx> wrote: > On Fri, May 13, 2011 at 4:20 AM, Christian Couder > <christian.couder@xxxxxxxxx> wrote: >> On Thu, May 12, 2011 at 7:15 PM, Andrew Lutomirski <luto@xxxxxxx> wrote: >>> >>> OK, this sucks. In the course of bisecting this, I've hit two other >>> apparently unrelated bugs that prevent my from testing large numbers >>> of kernels. Do I have two questions: >>> >>> 1. Anyone have any ideas from looking at the log? >>> >>> It looks like most of what's left is network code, so cc netdev. >>> >>> 2. The !&$#@ bisection is skipping all over the place. I've seen >>> 2.6.37 versions and all manner of -rc's out of order. Linus, and >>> other people who like pontificating about git bisection: is there any >>> way to get the bisection to follow Linus' tree? I think that if >>> bisect could be persuaded to consider only changes that are reached by >>> following only the *first* merge parent all the way from the bad >>> revision to the good revision, then the bisection would build versions >>> that were at least good enough for Linus to pull and might have fewer >>> bisection-killing bugs. >>> >>> (This isn't a new idea [1], and git rev-list --bisect --first-parent >>> isn't so bad except that it doesn't bisect.) >> >> Did you forget to put the reference [1] in your email? Was it this one >> you were thinking about: >> >> http://thread.gmane.org/gmane.comp.version-control.git/165433/ > > No, it was this: > > http://stackoverflow.com/questions/5638211/how-do-you-get-git-bisect-to-ignore-merged-branches > Sadly even that's not enough. I finished the bisection (by standard-ish techniques but with a bit of overriding of git bisect's choices and occasional merging of newer versions of -linus to get something that would boot) and it pointed to a commit that wasn't the culprit. The problem is that 2.6.39-rc7 is bad, 2.6.38 (and 2.6.38.{5,6}) is good, but 2.6.38-rc5 is bad and fails identically to 2.6.39-rc7. I think that git bisect makes the assumption that ancestors of a good commit are good, and that just isn't true for this bug. So what I really want is a fancy version of git bisect that makes no assumptions about the relationship of good and bad commits in the graph and just finds me a commit that is bad but for which all parents are good or vice versa. I'm currently bisecting the other way to find the commit before 2.6.38 that fixed the bug, since there's presumably less churn there than in the early bits of 2.6.39. --Andy -- 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