“The last couple of years have seen a renewed push within the
kernel community to avoid regressions. When a patch is found to
have broken something that used to work, a fix must be merged or
the offending patch will be removed from the kernel. It’s a
straightforward and logical idea, but there’s one little problem:
when a kernel series includes over 12,000 changesets (as 2.6.25
does), how does one find the patch which caused the problem?
Sometimes it will be obvious, but, for other problems, there are
literally thousands of patches which could be the source of the
regression. Digging through all of those patches in search of a bug
can be a needle-in-the-haystack sort of proposition.“One of the many nice tools offered by the git source code
management system is called ‘bisect…'”