| ▲ | assbuttbuttass 2 hours ago | |
That sounds like it would break bisect | ||
| ▲ | bonzini 21 minutes ago | parent | next [-] | |
You can develop with failing tests and reorder them after the code change before publishing your branch. | ||
| ▲ | Myrmornis 2 hours ago | parent | prev | next [-] | |
Fair. I think what I'd say is that we don't have to use plain git bisect -- it would be quick to make a bisect script that doesn't land on the failing-test commits. Especially seeing as most teams squash before merging, we should have the freedom to create failing-test commits. | ||
| ▲ | jolmg 2 hours ago | parent | prev | next [-] | |
Right, maybe a better way to get what they're going for would be | ||
| ▲ | locknitpicker an hour ago | parent | prev [-] | |
> That sounds like it would break bisect Nonsense. First off, you can pick the starting commit, and nothing forces you to pick the test one. Second, bisect is designed to tracks changes from good state to bad state based on your personal criteria of what good and bad is. This means that you are free to put up tests that make sense to you (i.e., all tests except the one that was added as a red test) and even not run a test at all. | ||