3 ms·

I think git bisect is one of the most useful tools that git gives you, and one that not many people use when they should. It's not every day one needs to bisect

by pvinis 10y ago

I think git bisect is one of the most useful tools that git gives you, and one that not many people use when they should. It's not every day one needs to bisect, but when you need to, it's very good to know about it. One of my worries with git bisect and other tools, is that it's very easy to use them when the application is very quick to test the correctness of it, but veeery slow if for each commit you checkout you need to restart some process, clear some cache, deploy something, repopulate some other thing, and then you can check for correctness. I guess the way to deal with that would be tests, but tests are not always the solution or even a possibility.

LyndsySimon 10y ago
Tests generally are the answer for the complex stuff in my experience. If it takes you more than a minute or so to check for the failure, then write a script to automate it. Once that's done, you can just run the script at each iteration of bisect, and you'll save time in the long run. The bonus is that the script you've written to determine a failure case will also serve as a regression test so that the same bug won't be reintroduced in the future. Adding the script as a regression test isn't always a possibility (you may not have a set of tests to add it to), but that's just a "value add" anyhow. Oh, and if you don't have tests at all, that's a huge red flag. That should be remedied as quickly as possible.
- pvinis 10y ago
  I agree, but what if this script takes itself 10 min to run because it has to do lots of work? That's the slow cases I mean. As for tests, of course it's great to have tests, but how do you test if a streaming video from a phone app is dropping more frames after a specific commit? there are things that are hard to test with a script. And usually these are the cases where bisect is very useful, because it reduces two weeks of debugging to two days. Which is still a long time.

by pvinis 10y ago

LyndsySimon 10y ago

Tests generally are the answer for the complex stuff in my experience. If it takes you more than a minute or so to check for the failure, then write a script to automate it. Once that's done, you can just run the script at each iteration of bisect, and you'll save time in the long run. The bonus is that the script you've written to determine a failure case will also serve as a regression test so that the same bug won't be reintroduced in the future. Adding the script as a regression test isn't always a possibility (you may not have a set of tests to add it to), but that's just a "value add" anyhow. Oh, and if you don't have tests at all, that's a huge red flag. That should be remedied as quickly as possible.

pvinis 10y ago
I agree, but what if this script takes itself 10 min to run because it has to do lots of work? That's the slow cases I mean. As for tests, of course it's great to have tests, but how do you test if a streaming video from a phone app is dropping more frames after a specific commit? there are things that are hard to test with a script. And usually these are the cases where bisect is very useful, because it reduces two weeks of debugging to two days. Which is still a long time.