The result of such a bisection would be that we would find that H is
the first bad commit, when in fact it's B. So that would be wrong!
-And yes it's can happen in practice that people working on one branch
+And yes it can happen in practice that people working on one branch
are not aware that people working on another branch fixed a bug! It
could also happen that F fixed more than one bug or that it is a
revert of some big development effort that was not ready to be
where c is the number of rounds of test (so a small constant) and b is
the ratio of bug per commit (hopefully a small constant too).
-So of course it's much better as it's O(N \* T) vs O(N \* T \* M) if
+So of course it's much better as it's O(N * T) vs O(N * T * M) if
you would test everything after each commit.
This means that test suites are good to prevent some bugs from being
The smaller the changes in your commit, the most effective "git
bisect" will be. And you will probably need "git bisect" less in the
first place, as small changes are easier to review even if they are
-only reviewed by the commiter.
+only reviewed by the committer.
Another good idea is to have good commit messages. They can be very
helpful to understand why some changes were made.