Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.kernel.org/pub/scm/git/git.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorÆvar Arnfjörð Bjarmason <avarab@gmail.com>2022-11-05 14:54:21 +0300
committerTaylor Blau <me@ttaylorr.com>2022-11-10 01:29:31 +0300
commit8354cf752ecbda5d369d6f83a818001eb66d1808 (patch)
tree1c12a2293df29c8ff88a702ec1e678977939a133 /t/t7610-mergetool.sh
parent319605f8f00e402f3ea758a02c63534ff800a711 (diff)
t7610: fix flaky timeout issue, don't clone from example.com
When t7610-mergetool.sh runs without failures the git://example.com submodule URLs will never be used. That's because we "git submodule add" it, but then manually populate them so that subsequent "git submodule update -N" won't attempt to clone it, only update it without fetching. But if we fail in an earlier test it'll have the knock-on effect of having later tests hang on that "git submodule update -N" as we attempt to clone this repository from example.com. This can be reproduced on "master" by running the test with SANITIZE=leak without "--immediate". With "GIT_TEST_PASSING_SANITIZE_LEAK=true" (which the linux-leaks job uses) we'll skip the test entirely. So we'll only run into this when running it manually, or with the "GIT_TEST_PASSING_SANITIZE_LEAK=check" mode. That's not because the failure has anything to do with leak detection per-se. It just so happens that we have a leak that'll fail before we've managed to fully set these up, and therefore "git submodule update -N" ends up spawning "git clone". Let's instead continue lying about the origin of this submodule by providing a URL for it that doesn't work, but now one that *really* doesn't work: /dev/null. If the test is passing we won't ever use this, and if we have knock-on failures we'll fail early, instead of waiting for a timeout. The behavior of "-N" here might be surprising to some, since it's explained as "[if you use -N we] don’t fetch new objects from the remote site". But (perhaps counter-intuitively) it's only talking about if it needs to do so via "git fetch". In this case we'll end up spawning a "git clone", as we have no submodule set up. See ff7f089ed10 (mergetool: Teach about submodules, 2011-04-13) for the commit that implemented these "example.com" tests. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com>
Diffstat (limited to 't/t7610-mergetool.sh')
-rwxr-xr-xt/t7610-mergetool.sh4
1 files changed, 2 insertions, 2 deletions
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index 8cc64729ad..b1ba0d9a08 100755
--- a/t/t7610-mergetool.sh
+++ b/t/t7610-mergetool.sh
@@ -33,7 +33,7 @@ test_expect_success 'setup' '
git add foo &&
git commit -m "Add foo"
) &&
- git submodule add git://example.com/submod submod &&
+ git submodule add /dev/null submod &&
git add file1 "spaced name" file1[1-4] subdir/file3 .gitmodules submod &&
git commit -m "add initial versions" &&
@@ -614,7 +614,7 @@ test_expect_success 'submodule in subdirectory' '
)
) &&
test_when_finished "rm -rf subdir/subdir_module" &&
- git submodule add git://example.com/subsubmodule subdir/subdir_module &&
+ git submodule add /dev/null subdir/subdir_module &&
git add subdir/subdir_module &&
git commit -m "add submodule in subdirectory" &&