Taylor Blau [off-list ref] writes:
On Mon, Jul 24, 2023 at 10:59:02AM +0200, Christian Couder wrote:
quoted
diff --git a/t/t5317-pack-objects-filter-objects.sh b/t/t5317-pack-objects-filter-objects.sh
index b26d476c64..2ff3eef9a3 100755
--- a/t/t5317-pack-objects-filter-objects.sh
+++ b/t/t5317-pack-objects-filter-objects.sh
@@ -53,6 +53,14 @@ test_expect_success 'verify blob:none packfile has no blobs' '
! grep blob verify_result
'
+test_expect_success 'verify blob:none packfile without --stdout' '
+ git -C r1 pack-objects --revs --filter=blob:none mypackname >packhash <<-EOF &&
+ HEAD
+ EOF
+ git -C r1 verify-pack -v "mypackname-$(cat packhash).pack" >verify_result &&
+ ! grep blob verify_result
+'
Just a couple of style nits here. It's a little strange (for me, at
least) to see the heredoc into a git process.
FWIW, "git" is after all no different from any other command and
redirecting here-doc, especially with an option like "--stdin" is in
effect, is perfectly sensible, I think. Preparing an input in a
file (e.g. "cat >file <<EOF" followed by "git cmd <file") might give
you slightly a better debuggability, but I do not sense that it is
what you are worried about.
... I am less certain
about redirecting the output into a file "packhash", only to cat it back
out.
But that would make the syntax awkward. Do you mean something along
this line?
var=$(git ... <<-EOF
here text
EOF
) &&
git ... mypackname-$var.pack &&
...
Somehow here-doc and $(command subsitution) does not visually mix
well.
Also, $var will not be inspectable when running this test under "-i
-v", so it hurts debuggability without taking the output in a
temporary file. You could do "-x", of course, but that would make
everything ultra verbose, so...