You can also check out this article and more, with better syntax highlighting, on my blog: https://blog.jimmydc.com/git-bisect/
I have this method for finding a bug when it is showing itself to be particularly tricky to locate or reproduce. I have called it the “binary search method” for a while now, because I never bothered to come up with an actually good name and it is described quite well by this one, but only if you know what a binary search is.
A binary search can be simplified to cutting a sorted list in half and seeing if the middle is what you were looking for, or if it is greater or less than what you are looking for. You keep repeating this process, chopping in half what you just chopped in half, until you get to what you were looking for. Feel free to look it up for a more accurate and thorough description, but I think this will suffice for this article.
Before I move on, if you prefer to jump right to code examples I have created an Example Repository with instructions in the readme for trying it out. The rest of this article will be my longform explanation about my debugging techniques, git bisect, and an example of when it is useful. I’ve also got something really cool at the end of the article.
So what I do is pretty simple, yet extremely effective when I’ve exhausted the “easy” ways of finding a bug. I put a bunch of logs in my code, and then I delete/comment out about half the code. I run my code, check the logs, and see if the bug goes away. Sometimes this is as easy as deleting the bottom half of a page, or removing a whole import of a file. Sometimes it takes a little more finesse, because the code might not be written into small enough units/functions.
I am not intending to say I pioneered this method, as I’m sure many others have thought of it. I do introduce it to fellow programmers quite often, though, so I wanted to describe it briefly for anyone not familiar. Now that you have the background, let us move on to the real subject of the article.
#terminal #git #bisect #jest #git-bisect