Ram Rachum <r...@rachum.com> writes: > Administrator@Turing ~/Dropbox/Desktop/foo (development) > $ git bisect start > > Administrator@Turing ~/Dropbox/Desktop/foo (development|BISECTING) > $ git bisect good 3068 > > Administrator@Turing ~/Dropbox/Desktop/foo (development|BISECTING) > $ git bisect bad b7a8 > Bisecting: 0 revisions left to test after this (roughly 1 step) > [0aa833916e908ea93902a6c4c227f9a884a1bcef] Merge branch 'master' into > development > > Administrator@Turing ~/Dropbox/Desktop/foo ((0aa8339...)|BISECTING) > $ git bisect bad > Bisecting: 0 revisions left to test after this (roughly 0 steps) > [24139451ab954b1f0a9ef616775a3dba0ac81669] Creating some-file > > Administrator@Turing ~/Dropbox/Desktop/foo ((2413945...)|BISECTING) > $ git bisect bad > 24139451ab954b1f0a9ef616775a3dba0ac81669 is the first bad commit > commit 24139451ab954b1f0a9ef616775a3dba0ac81669 > Author: Ram Rachum <r...@rachum.com> > Date: Tue Apr 19 16:01:28 2016 +0300 > > Creating some-file > > :000000 100644 0000000000000000000000000000000000000000 > e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 A some-file > > Administrator@Turing ~/Dropbox/Desktop/foo ((2413945...)|BISECTING) > $
OK, I've had to learn some things first. One is that git-bisect doesn't find the commit along the path between a good commit and a bad commit that introduces a bug. You specify a bad commit and git-bisect finds an "original bad" ancestor: a commit that is an ancestor of the specified bad commit that is bad and has no parent that is bad. In this case, your command "git bisect good 3068" does *not* restrict git-bisect's attention to the commits in 3068..b7a8. It just tells git-bisect that 3068 is good. git-bisect still has to check the ancestors of 2413, which are ancestors of b7a8 but not ancestors of 3068. With this definition, it's clear that git-bisect should identify cf02 as the "original bad" commit, because it's the only one. If it doesn't, that's a bug in Git. And I'm not so surprised that it doesn't handle that special case correctly, it's not an obvious one. You should report that as a problem on the main Git mailing list. Now to solve your problem: What you need to do is redefine "bad" to mean "should have sugar but does not". That is, "is a descendant of 3068 and does not have sugar". When you do that, 2413 becomes good, because it's not a descendant of 3068. And I'll bet that if you say "git bisect good" for 2413 you will get the result you expect. Dale -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
