Re: What's cooking in git.git (Mar 2018, #01; Thu, 1)
- Date: Fri, 2 Mar 2018 19:55:54 +0100
- From: SZEDER Gábor <szeder.dev@xxxxxxxxx>
- Subject: Re: What's cooking in git.git (Mar 2018, #01; Thu, 1)
On Fri, Mar 2, 2018 at 6:11 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> OK, I think I now understand what happened. I misread the "fold"
> discussion and thought we were still exploring the possibility, to
> avoid showing uninteresting zero-status case to the users.
> If we do not care about that part, then it seems that the discussion
> thread is complete. Let's move on.
I think we don't care much about folding, at least not in conjunction
with the patch in question. And even if we change our minds in the
future, we can always add that on top.
Note that nowadays there is a _different_ issue that may make folding
Recently we started to run the test suite twice in one of the Linux
build jobs: once "as usual" and once with split index enabled. If a
test fails in this build job, then it's impossible to tell which one of
the two test runs failed just by looking at the end of the build job's
log; one has to scroll back to the start of the failed test run to see
the executed command shown by the 'set -x' trace. Now, if the failure
happened in the split index enabled test run, then this line is
somewhere in the middle of the looong log (even without the patch in
question!), which is a bit inconvenient to find. If the outputs of
building Git _and_ the "as usual" test run were folded, then this line
would be closer to the top and easier to find.
Though, arguably, if all or most of the other build jobs have succeeded,
then it's quite likely that the failure happened in the split index
enabled test run. And if the other build jobs have failed as well,
then, on one hand, the failure is almost certainly in the "as usual"
test run, and, on the other hand, one can check the output of any of
those other failed build jobs to see what went wrong. As far as I
observed, the failure tends to happen in the split index enabled test
run most of the time ;) and I have a couple of patches almost ready for
submission to address some of the transient failures related to split
 - ae59a4e44f (travis: run tests with GIT_TEST_SPLIT_INDEX,