4 ms·

Are you suggesting using the unit tests at the HEAD selected by the current git bisect step as the binary signal for bisect? Because if so, I agree that a comm

Are you suggesting using the unit tests at the HEAD selected by the current git bisect step as the binary signal for bisect? Because if so, I agree that a commit that introduces a failing test will break bisect (there will be a pass->fail transition AND a fail->pass transition, and bisecting requires there to be at most one such transition). But even more importantly: Without the separate commit containing only the failing test, every commit will pass. That is, bisect will have no useful signal at all. I think that can't be what you're suggesting, so could you clarify what bisect process you have in mind?

chris_wot 3y ago
Sure, there have been occassions where on a particular architecture or there is a particular set of circumstances where a test will succeed on a particular system but will fail elsewhere. If you try to bisect such a situation, you'll not be able to run git bisect run on your tests because of the failing test. I'm not against a failing test being committed, but I believe it isn't hugely productive. The test failing is surely a signal only to the developer who wrote the test that it failed? Or perhaps it should be failed on a seperate branch and then merged to the master branch, which is pristine. Every organisation has there own workflow, I suppose. Edit: a crucial bit of info I didn't note was that you keep developing and add a lot more commits before it is noticed.