Improved Git Bisect Workflow and Best Practices

if the first bad commit is "B" and if it has been fixed in the "main" branch by commit "F"? 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 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 released. In fact development teams often maintain both a development branch and a maintenance branch, and it would be quite easy for them if "git bisect" just worked when they want to bisect a regression on the development branch that is not on the maintenance branch. They should be able to start bisecting using: ------------- $ git bisect start dev main ------------- To enable that additional nice feature, when a bisection is started and when some good commits are not ancestors of the bad commit, we first compute the merge bases between the bad and the good commits and we chose these merge bases as the first commits that will be checked out and tested. If it happens that one merge base is bad, then the bisection process is stopped with a message like: ------------- The merge base BBBBBB is bad. This means the bug has been fixed between BBBBBB and [GGGGGG,...]. ------------- where BBBBBB is the sha1 hash of the bad merge base and [GGGGGG,...] is a comma separated list of the sha1 of the good commits. If some of the merge bases are skipped, then the bisection process continues, but the following message is printed for each skipped merge base: ------------- Warning: the merge base between BBBBBB and [GGGGGG,...] must be skipped. So we cannot be sure the first bad commit is between MMMMMM and BBBBBB. We continue anyway. ------------- where BBBBBB is the sha1 hash of the bad commit, MMMMMM is the sha1 hash of the merge base that is skipped and [GGGGGG,...] is a comma separated list of the sha1 of the good commits. So if there is no bad merge base, the bisection process continues as usual after this step. Best bisecting practices ------------------------ Using test suites and git bisect together ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you both have a test suite and use git bisect, then it becomes less important to check that all tests pass after each commit. Though of course it is probably a good idea to have some checks to avoid breaking too many things because it could make bisecting other bugs more difficult. You can focus your efforts to check at a few points (for example rc and beta releases) that all the T test cases pass for all the N configurations. And when some tests don't pass you can use "git bisect" (or better "git bisect run"). So you should perform roughly: ------------- c * N * T + b * M * log2(M) tests ------------- 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 you would test everything after each commit. This means that test suites are good to prevent some bugs from being committed and they are also quite good to tell you that you have some bugs. But they are not so good to tell you where some bugs have been introduced. To tell you that efficiently, git bisect is needed. The other nice thing with test suites, is that when you have one, you already know how to test for bad behavior. So you can use this knowledge to create a new test case for "git bisect" when it appears that there is a regression. So it will be easier to bisect the bug and fix it. And then you can add the test case you just created to your test suite. So if you know how to create test cases and how to bisect, you will be subject to a virtuous circle: more tests => easier to create tests => easier to bisect => more tests So test suites and "git bisect" are complementary tools that are very

This text describes how Git bisect can be improved to handle cases where the bad commit is not an ancestor of the good commit, by computing merge bases and testing them first. It also discusses best practices for using Git bisect, including using test suites to reduce the number of tests needed, and how test suites and Git bisect can be used together to create a virtuous circle of testing and debugging, making it easier to identify and fix regressions.