Thanks for explaining it so well! I really struggle to understand when I'd use this in my workflow, and you did a great job showing examples of that.
So, if all the tests ran on every commit, this would be less useful- unless they were something like performance tests that were relatively subjective.
Usually I try and find the bug, then look at the history for that line or file to see why that change was made, in effect doing almost the opposite of bisect.
Thanks for explaining it so well! I really struggle to understand when I'd use this in my workflow, and you did a great job showing examples of that.
So, if all the tests ran on every commit, this would be less useful- unless they were something like performance tests that were relatively subjective.
Usually I try and find the bug, then look at the history for that line or file to see why that change was made, in effect doing almost the opposite of bisect.
I'll try and use bisect, see if it improves my!
Yes, the real beauty of bisect is that it does a binary search, which makes it way faster and easier to find the broken commit