On 12/12, Junio C Hamano wrote: > 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. Sorry, indeed I misunderstood you. I do agree with the above. > >> 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. Yeah I'd be happy with something like that. And I see there's some more discussion about it in another part of the thread, will follow up there. Thanks!
