JavaScript wrangler.
Check out my books!
Web API Cookbook:
https://www.amazon.com/Web-API-Cookbook-JavaScript-Applications/dp/1098150694
Modern CSS:
https://www.amazon.com/dp/148426293X
git bisect is a life saver! It has saved my bacon several times. If you have automated tests, you can even run bisect on autopilot, if the test has a 0 exit status, it treats it as good, if it has a non-zero exit status, it treats it as bad. Just start it, go get some coffee, and come back to find your bad commit!
It seems like if you're using a continuous integration model though where your tests are always running on each commit, and it's required that your tests pass before you're allowed to merge your new code into the master branch, you wouldn't end up in a situation in which you have failing tests on your master branch. Right?
So is automating git bisect assuming that you're not enforcing 100% passing tests? Or would you run it on your own branch in which you have multiple commits that haven't had their tests validated and you've introduced a bug somewhere in there, but you still haven't merged to master yet? Or what's the use case here?
JavaScript wrangler.
Check out my books!
Web API Cookbook:
https://www.amazon.com/Web-API-Cookbook-JavaScript-Applications/dp/1098150694
Modern CSS:
https://www.amazon.com/dp/148426293X
I think the use case would be if you uncover a bug that you don't have an automated test for, but you can then write one that reproduces the bug. Then you run git bisect in automatic mode. Once the issue is fixed, you can add that new test to your test suite. 🤷♂️That's the best one I can think of.
git bisectis a life saver! It has saved my bacon several times. If you have automated tests, you can even run bisect on autopilot, if the test has a 0 exit status, it treats it as good, if it has a non-zero exit status, it treats it as bad. Just start it, go get some coffee, and come back to find your bad commit!see here for more details: lwn.net/Articles/317154/
Neat! Thanks for sharing.
It seems like if you're using a continuous integration model though where your tests are always running on each commit, and it's required that your tests pass before you're allowed to merge your new code into the master branch, you wouldn't end up in a situation in which you have failing tests on your master branch. Right?
So is automating
git bisectassuming that you're not enforcing 100% passing tests? Or would you run it on your own branch in which you have multiple commits that haven't had their tests validated and you've introduced a bug somewhere in there, but you still haven't merged to master yet? Or what's the use case here?That's a good point.
I think the use case would be if you uncover a bug that you don't have an automated test for, but you can then write one that reproduces the bug. Then you run git bisect in automatic mode. Once the issue is fixed, you can add that new test to your test suite. 🤷♂️That's the best one I can think of.
Ooh didn't know about
git bisect run.Wouldn't that be too slow for web apps that have no compilation step?