3 ms·
Suppose we have a failing test. For many commits, gp carefully separated their change that would break our test, from the change that would fix the test. At som
by assbuttbuttass 3mo ago
Suppose we have a failing test. For many commits, gp carefully separated their change that would break our test, from the change that would fix the test. At some point, someone forgot to run the tests, and introduced a commit that broke the test without adding a second commit to fix it. Now it's treated as a "pre-existing failure," and many more commits are added on top.
How would you identify the commit that broke the test?
- locknitpicker 3mo ago> How would you identify the commit that broke the test? You're asking how to use bisect. You start with a range of commits you picked. All that bisect does is help you search for a commit within that range that introduces a regression. The responsibility to specify which commits you cover is yours, not the tool.
- assbuttbuttass 3mo agoAnd then bisect fails because it finds one of the many commits that broke the test before the actual regression
- locknitpicker 3mo ago> And then bisect fails because it finds one of the many commits that broke the test before the actual regression And that's ok. You skip the commit and move on with your life.