From 1c1f6e03e1fbd92e1785bc21f6974dd036790a44 Mon Sep 17 00:00:00 2001 From: Jonathan Nieder Date: Wed, 7 Aug 2019 23:56:14 -0700 Subject: [PATCH 1/2] t: decrease nesting in test_oid_to_path t1410.3 ("corrupt and checks") fails when run using dash versions before 0.5.8, with a cryptic message: mv: cannot stat '.git/objects//e84adb2704cbd49549e52169b4043871e13432': No such file or directory The function generating that path: test_oid_to_path () { echo "${1%${1#??}}/${1#??}" } which is supposed to produce a result like 12/3456789.... But a dash bug[*] causes it to instead expand to /3456789... The stream of symbols that makes up this function is hard for humans to follow, too. The complexity mostly comes from the repeated use of the expression ${1#??} for the basename of the loose object. Use a variable instead --- nowadays, the dialect of shell used by Git permits local variables, so this is cheap. An alternative way to work around [*] is to remove the double-quotes around test_oid_to_path's return value. That makes the expression easier for dash to read, but harder for humans. Let's prefer the rephrasing that's helpful for humans, too. Noticed by building on Ubuntu trusty, which uses dash 0.5.7. [*] Fixed by v0.5.8~13 ("[EXPAND] Propagate EXP_QPAT in subevalvar, 2013-08-23). Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano --- t/test-lib-functions.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh index 7860491660..de58e8b502 100644 --- a/t/test-lib-functions.sh +++ b/t/test-lib-functions.sh @@ -1337,7 +1337,8 @@ test_oid () { # Insert a slash into an object ID so it can be used to reference a location # under ".git/objects". For example, "deadbeef..." becomes "de/adbeef..". test_oid_to_path () { - echo "${1%${1#??}}/${1#??}" + local basename=${1#??} + echo "${1%$basename}/$basename" } # Choose a port number based on the test script's number and store it in From 7f0b5908759c59b77b39c62184166325e30f8878 Mon Sep 17 00:00:00 2001 From: Jeff King Date: Thu, 8 Aug 2019 05:37:33 -0400 Subject: [PATCH 2/2] t0000: reword comments for "local" test Commit 01d3a526ad (t0000: check whether the shell supports the "local" keyword, 2017-10-26) added a test to gather data on whether people run the test suite with shells that don't support "local". After almost two years, nobody has complained, and several other uses have cropped up in test-lib-functions.sh. Let's declare it acceptable to use. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano --- t/t0000-basic.sh | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh index 31de7e90f3..60c6610ec0 100755 --- a/t/t0000-basic.sh +++ b/t/t0000-basic.sh @@ -25,16 +25,14 @@ try_local_x () { echo "$x" } -# This test is an experiment to check whether any Git users are using -# Shells that don't support the "local" keyword. "local" is not +# Check whether the shell supports the "local" keyword. "local" is not # POSIX-standard, but it is very widely supported by POSIX-compliant -# shells, and if it doesn't cause problems for people, we would like -# to be able to use it in Git code. +# shells, and we rely on it within Git's test framework. # -# For now, this is the only test that requires "local". If your shell -# fails this test, you can ignore the failure, but please report the -# problem to the Git mailing list , as it might -# convince us to continue avoiding the use of "local". +# If your shell fails this test, the results of other tests may be +# unreliable. You may wish to report the problem to the Git mailing +# list , as it could cause us to reconsider +# relying on "local". test_expect_success 'verify that the running shell supports "local"' ' x="notlocal" && echo "local" >expected1 &&