From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Subject: [PATCH] t5702: be more resilient to env quoting
Date: Fri, 30 Oct 2026 20:25:50 -0400 [thread overview]
Message-ID: <20261031002550.GA626623@coredump.intra.peff.net> (raw)
A few tests in t5702 check whether we specify the v2 protocol via the
GIT_PROTOCOL environment variable. They do this by redirecting the
output of "env" into a file and grepping it. But our exact pattern
depends on how env quotes its output. GNU coreutils 9.10 will output
this:
GIT_PROTOCOL=version=2
but version 9.12 will output this:
GIT_PROTOCOL='version=2'
It doesn't quote every variable, but the presence of "=" now triggers
it. We could loosen our regex to accommodate both versions, but there's
a simpler fix. We only care about the value of one variable, so we can
just print it using the shell invoked for the server-side command.
Note that this new formula is slightly less strict: it allows
GIT_PROTOCOL as an empty string in addition to it being missing. But
that's OK; they both mean the same thing to the child Git process.
Likewise, it's actually more strict when we do expect the v2 protocol:
it checks the contents of the whole GIT_PROTOCOL rather than a partial
grep. In practice it's the same for now (we only ever set protocol=2),
but I think in the long run being strict is better (if we do add
something else, the test will break and we can consider how to handle it
then).
Signed-off-by: Jeff King <peff@peff.net>
---
The new coreutils hit Debian unstable, so I ran into this doing my usual
daily "make test". I wondered what idiot did the overly-complicated
"env" invocation in the first place, but naturally it turns out it was
me.
t/t5702-protocol-v2.sh | 23 +++++++++++++++--------
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/t/t5702-protocol-v2.sh b/t/t5702-protocol-v2.sh
index 7e69ba7f84..a66adfbc3b 100755
--- a/t/t5702-protocol-v2.sh
+++ b/t/t5702-protocol-v2.sh
@@ -929,28 +929,35 @@ test_expect_success 'file:// --negotiate-only with protocol v0' '
test_expect_success 'push with custom path does not request v2' '
rm -f env.trace &&
git -C client push \
- --receive-pack="env >../env.trace; git-receive-pack" \
+ --receive-pack="
+ echo GIT_PROTOCOL=\$GIT_PROTOCOL >../env.trace
+ git-receive-pack" \
origin HEAD:refs/heads/custom-push-test &&
- test_path_is_file env.trace &&
- test_grep ! ^GIT_PROTOCOL env.trace
+ echo GIT_PROTOCOL= >expect &&
+ test_cmp expect env.trace
'
test_expect_success 'fetch with custom path does request v2' '
rm -f env.trace &&
git -C client fetch \
- --upload-pack="env >../env.trace; git-upload-pack" \
+ --upload-pack="
+ echo GIT_PROTOCOL=\$GIT_PROTOCOL >../env.trace
+ git-upload-pack" \
origin HEAD &&
- test_grep ^GIT_PROTOCOL=version=2 env.trace
+ echo GIT_PROTOCOL=version=2 >expect &&
+ test_cmp expect env.trace
'
test_expect_success 'archive with custom path does not request v2' '
rm -f env.trace &&
git -C client archive \
- --exec="env >../env.trace; git-upload-archive" \
+ --exec="
+ echo GIT_PROTOCOL=\$GIT_PROTOCOL >../env.trace
+ git-upload-archive" \
--remote=origin \
HEAD >/dev/null &&
- test_path_is_file env.trace &&
- test_grep ! ^GIT_PROTOCOL env.trace
+ echo "GIT_PROTOCOL=" >expect &&
+ test_cmp expect env.trace
'
test_expect_success 'reject client packfile-uris if not advertised' '
--
2.56.0.613.g16c2199927
next reply other threads:[~2026-10-31 0:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-31 0:25 Jeff King [this message]
2026-10-31 2:03 ` [PATCH] t5702: be more resilient to env quoting Todd Zullinger
2026-10-31 5:06 ` Jeff King
2026-10-31 5:08 ` Collin Funk
2026-10-31 5:21 ` Collin Funk
2026-10-31 3:12 ` Junio C Hamano
2026-10-31 5:03 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261031002550.GA626623@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox