On Wednesday 04 November 2009, Junio C Hamano wrote: > Christian Couder <chriscool@xxxxxxxxxxxxx> writes: > > So to do that you would use "git bisect start ..." and then you could > > use: > > > > $ git rev-list --bisect HEAD --not $GOOD_COMMITS > > > > to get the commit that you would have to test if the current commit is > > bad and: > > > > $ git rev-list --bisect $BAD --not $GOOD_COMMITS HEAD > > > > to get the commit that you would have to test if the current commit is > > good. > > Even in that case, the problem is still about narrowing the set of the > current bisection graph. If --bisect option implicitly grabs good and > bad defined in the refspace like Linus's patch does, it will give you the > same behaviour of the above two commands, no? I think it will probably work when you add a good rev, but in the case where you give a different bad (the first command above) it does not work the same. The test case in patch 1/3 shows that. It does: git bisect start $HASH7 $HASH1 && ... rev_list2=$(git rev-list --bisect $HASH3 --not $HASH1) && test "$rev_list2" = "$HASH2" and that last command fails. Best regards, Christian. -- 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