> On 04 Jan 2018, at 21:13, Thomas Gummerer <t.gummerer@xxxxxxxxx> wrote: > > On 12/18, Lars Schneider wrote: >> >>> On 17 Dec 2017, at 23:51, Thomas Gummerer <t.gummerer@xxxxxxxxx> wrote: >>> >>> Split index mode only has a few dedicated tests, but as the index is >>> involved in nearly every git operation, this doesn't quite cover all the >>> ways repositories with split index can break. To use split index mode >>> throughout the test suite a GIT_TEST_SPLIT_INDEX environment variable >>> can be set, which makes git split the index at random and thus >>> excercises the functionality much more thoroughly. >>> >>> As this is not turned on by default, it is not executed nearly as often >>> as the test suite is run, so occationally breakages slip through. Try >>> to counteract that by running the test suite with GIT_TEST_SPLIT_INDEX >>> mode turned on on travis. >>> >>> To avoid using too many cycles on travis only run split index mode in >>> the linux-gcc and the linux 32-bit gcc targets. >> >> I am surprised to see the split index mode test for the linux 32-bit >> target. Is it likely that a split index bug appears only on 32-bit? >> Wouldn't the linux-gcc target be sufficient to save resources/time? > > I'm not sure it's particularly likely for a bug to appear only on > 32-bit builds. It also doesn't seem to take too long to run, so I > thought I'd add it just in case, but I'm happy running the tests only > in the 64-bit builds if that's preferred. CI running times naturally add up over time as more and more stuff is tested. That's why I would argue testing GIT_TEST_SPLIT_INDEX on 64-bit is probably sufficient. However, I am not really familiar with GIT_TEST_SPLIT_INDEX. There is no right or wrong here and either way is fine with me. I just wanted to express my "keep an eye on CI time" concern. Thanks, Lars
