Thomas Gummerer <t.gummerer@xxxxxxxxx> writes: > > The breakages wen the split-index code fails tend to break things in > much more obvious manners than a wrong message, usually git ends up > dying if it gets broken. Both of the bugs that were fixed here would > have been caught with the change in my patch. > > But yeah I can see the argument that it doesn't give us a guarantee > that it catches all things the test suite could catch. I think you misunderstood me. When split index is much easier to break than poison tests, combining them together would hurt the test coverage of poison tests. If you value poison tests much more than how well split index mode works, that is a worse outcome. >> I wonder if it makes more sense to update ci/run-tests.sh so that >> its final step is run twice with different settings, like so? > > I kind of wanted to avoid that, because it ends up running the test > suite twice on travis for every test, which seems a bit overkill. But > I don't exactly how worried we are about cycles on travis (I don't > check it very often personally, so I don't really know). If we aren't > worried about cycles what you have below would certainly make sense. I think 64-bit gcc/clang builds tend to cost us about 10-20 minutes each, and 32-bit linux builds about 10 minutes or so. I wonder if it makes sense to do the "run twice" for only one of 64-bit builds (perhaps the clang one, as I suspect 32-bit linux one uses gcc) and the 32-bit linux build, and nowhere else.