Hello, Johannes Schindelin wrote: > Hi, > > On Fri, 16 Mar 2007, Uwe Kleine-König wrote: > > > zeisberg@cassiopeia:~/gsrc/linux-2.6$ git bisect good > > Bisecting: 2 revisions left to test after this > > [e7b0d26a86943370c04d6833c6edba2a72a6e240] sysfs: reinstate exclusion between method calls and attribute unregistration > > > > zeisberg@cassiopeia:~/gsrc/linux-2.6$ git bisect good > > Bisecting: 2 revisions left to test after this > > [b810cdfcf91d76f603fd48023aede48ced8e6bed] Merge branch 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6 > > The problem is that after the first git-bisect good, it looks like this: > > g1 - b2 - b1 - M - B > / > g2 - b3 I wonder if bisect really knows that B is bad. git bisect visualize doesn't mark B (i.e. bac6eefe96204d0ad67d144f2511a6fc487aa594) bad. Maybe the problem is, that this is a tag and not a commit? After 2 more "bisect good"s I once more get B to test. If I mark that as good, I get "... was both good and bad"? The commandline is: git-rev-list --bisect '^069f8256362b7a17da532f0631cee73b4cfee65b' '^08e15e81a40e3241ce93b4a43886f3abda184aa6' '^0bdd0f385a44344f83409b9e00797bfe2596faf8' '^2cb8a57b9851805883dfe92cf5d88a726134a384' '^6ab27c6bf38d5ff71dafeca77b79e7c284804b75' '^a7c999114ecd0c69bd3970272b64d8842b765b21' '^b810cdfcf91d76f603fd48023aede48ced8e6bed' '^bdf3aaf9519ddd8a026b5e04e713d2fa673532e5' '^e7b0d26a86943370c04d6833c6edba2a72a6e240' bac6eefe96204d0ad67d144f2511a6fc487aa594 -- Maybe better "git-rev-list --bisect $good $bad^ --" should be used to find the bisection point? > P.S.: if Momo's turtle thinks that your name contains no non-ASCIIs, why > should I? You should differentiate between my user name and my real name. Best regards Uwe -- Uwe Kleine-König $ dc << EOF [d1-d1<a]sa99d1<a1[rdn555760928P*pz1<a]salax EOF - 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