Linux 2.6.26-rc1
-:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile
+:100644 100644 5cf82581... 4492984e... M Makefile
-------------
At this point we can see what the commit does, check it out (if it's
Linux 2.6.26-rc1
-:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile
+:100644 100644 5cf82581... 4492984e... M Makefile
bisect run success
-------------
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.