Yes, but if you run git bisect and then try to run your unit tests, a failure that was intentional will tell the bisect to potentially divide the commits at the wrong point.
You'd need to either exclude the test (probably not a great idea) or mark the commits as skippable. Also not a great idea.
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?
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.
