@@ -177,6 +177,7 @@ test_expect_success "submodule.recurse option triggers recursive fetch" '
'
test_expect_success "fetch --recurse-submodules -j2 has the same output behaviour" '
+ test_when_finished "rm -f trace.out" &&
add_submodule_commits &&
(
cd downstream &&
@@ -704,17 +705,25 @@ test_expect_success "'fetch.recurseSubmodules=on-demand' works also without .git
test_expect_success 'fetching submodules respects parallel settings' '
git config fetch.recurseSubmodules true &&
+ test_when_finished "rm -f downstream/trace.out" &&
(
cd downstream &&
GIT_TRACE=$(pwd)/trace.out git fetch &&
grep "1 tasks" trace.out &&
+ >trace.out &&
+
GIT_TRACE=$(pwd)/trace.out git fetch --jobs 7 &&
grep "7 tasks" trace.out &&
+ >trace.out &&
+
git config submodule.fetchJobs 8 &&
GIT_TRACE=$(pwd)/trace.out git fetch &&
grep "8 tasks" trace.out &&
+ >trace.out &&
+
GIT_TRACE=$(pwd)/trace.out git fetch --jobs 9 &&
- grep "9 tasks" trace.out
+ grep "9 tasks" trace.out &&
+ >trace.out &&
)
'
Fix test patterns added in 62104ba14af (submodules: allow parallel fetching, add tests and documentation, 2015-12-15) and a028a1930c6 (fetching submodules: respect `submodule.fetchJobs` config option, 2016-02-29). In the former case we were leaving a trace.out file at the top-level for any subsequent tests (there are none, currently). Let's clean the file up instead. In the latter case we were testing that a given configuration would result in "N tasks" in the log, but we were grepping through the log for all previous such tests, when we really meant to clear the logs between the "grep" invocations. In practice this resulted in no logic error, as e.g. "--fetch 7" would not print out a "9 tasks" line, but let's be paranoid and stop implicitly assuming that that's the case. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> --- t/t5526-fetch-submodules.sh | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)