These tests are just trying to show that we allow recursion up to a certain depth, but not past it. But the counting is a bit non-intuitive, and rather than test at the edge of the breakage, we test "OK" cases in the middle of the chain. Let's explain what's going on, and explicitly test the switch between "OK" and "too deep". Signed-off-by: Jeff King <peff@xxxxxxxx> --- t/t5613-info-alternate.sh | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/t/t5613-info-alternate.sh b/t/t5613-info-alternate.sh index 7bc1c3c..b393613 100755 --- a/t/t5613-info-alternate.sh +++ b/t/t5613-info-alternate.sh @@ -39,6 +39,18 @@ test_expect_success 'preparing third repository' ' ) ' +# Note: These tests depend on the hard-coded value of 5 as "too deep". We start +# the depth at 0 and count links, not repositories, so in a chain like: +# +# A -> B -> C -> D -> E -> F -> G -> H +# 0 1 2 3 4 5 6 +# +# we are OK at "G", but break at "H". +# +# Note also that we must use "--bare -l" to make the link to H. The "-l" +# ensures we do not do a connectivity check, and the "--bare" makes sure +# we do not try to checkout the result (which needs objects), either of +# which would cause the clone to fail. test_expect_success 'creating too deep nesting' ' git clone -l -s C D && git clone -l -s D E && @@ -47,16 +59,12 @@ test_expect_success 'creating too deep nesting' ' git clone --bare -l -s G H ' -test_expect_success 'invalidity of deepest repository' ' - test_must_fail git -C H fsck -' - -test_expect_success 'validity of third repository' ' - git -C C fsck +test_expect_success 'validity of fifth-deep repository' ' + git -C G fsck ' -test_expect_success 'validity of fourth repository' ' - git -C D fsck +test_expect_success 'invalidity of sixth-deep repository' ' + test_must_fail git -C H fsck ' test_expect_success 'breaking of loops' ' -- 2.10.0.618.g82cc264