Yeah, but usually you take the weight of the revisions (e.g. makefile regenerations/minor edits or unrelated minor target changes) into consideration so that each side of the bisection has about equal "weight".
Well, I've gone a similar, but 3rd way...
If (and only if) I knew the file/folder that likely caused the issue (i.e, a bug in SynEdit, likely caused by a commit to a SynEdit file).
I displayed a filtered log, and then visually picked the middle.
Or even read commit messages, and ignored "updated translations"
However, this is "visually picked the middle" because revisions are not continuous in that filtered log. (So the svn advantage is gone).
Of course, this only works if the filtered list, is small enough....
----
But, since the "svn advantage is gone", that can be done in GIT too. I can display the filtered log. I can see the list, and pick the middle.
On the other hand, and here comes the real difference....
I have not yet done that, but I will most likely in future.
I can write a script (or I might adapt lazbuild for that) => to return an exit code, indicating if all was fine (testcase run and succeeded) or not.
And then I can give that script to git. And can go, get my coffee, and git will bisect the revison without me doing any further work.
And if git does it all on its own, I do not care if the bisect need a few searches more or less.
(Yes, I can write a wrapper for svn too. But git already includes it)