> because "the bug was reintroduced" is essentially equivalent to "a lower number showed up later" Yes, and this is perfectly okay for "git bisect". > Need fo

> because "the bug was reintroduced" is essentially equivalent to "a lower number showed up later" Yes, and this is perfectly okay for "git bisect". > Need for sorting the list is essentially the same in both cases. No, bisection does not require sorting, it just needs a continuous range whose endpoints have different signs. Then, it will always find one point where the signs on both sides differ. (In real analysis, this means finding a zero. In discrete maths, it means find the introduction of a sign change.) In other words, when starting with a range from an old "good" commit to the current "bad" commit, it will always find a "good" commit directly followed by a "bad" commit. This is why "bisection" is a good term for this Git algorithm, while "binary search" would be misleading. (Even though bisection and binary search are almost identical algorithms. They mostly differ in their input assumptions and output guarantees.) Bisection makes no assumtion on any sort order, but guarantees to find one point of bug introduction in logarithmic time. It does not give any guarantee to find the lastest point of bug introduction -- unless, of course, your history does have just one such point.