On Wed, 21 Mar 2007, Uwe Kleine-König wrote: > > Up to now the number printed was calculated assuming that the current revision > to test is bad. Given that it's not possible that this always matches the > number of suspicious revs if the current one is good, the maximum of both is > taken now. How about adding a new flag to "git-rev-list", to make it count both ways? Doing this whole nr = $(eval "git-rev-list ... | wc -l") was ugly to begin with, and you just made it doubly ugly. And the thing is, "git-rev-list --bisect" will obviously already have calculated these numbers just to _pick_ the revision in the first place, so it's a bit sad then execute it twice more (giving it back the result *it* gave us in the first place!). So we could perhaps change the original rev=$(eval "git-rev-list --bisect $good $bad -- $(cat $GIT_DIR/BISECT_NAMES)") with something nicer. (In fact, I would also suggest we drop or try to fix BISECT_NAMES support, while at it - it never really worked, and iirc it was partly exactly *because* of the end-condition not being handled right). Linus