Re: [BUG] 2.46.0 t7701.09 fails on NonStop ia64

From: Taylor Blau <me@ttaylorr.com>
Date: Aug 4, 2024, 18:12 UTC
Message-ID: <Zq/ElpJpbcUqB+4e@nand.local>
In-Reply-To: <04f101dae68c$c57574b0$50605e10$@nexbridge.com>

On Sun, Aug 04, 2024 at 12:38:38PM -0400, rsbecker@nexbridge.com wrote:

Show 10 quoted lines

> ./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index < .git/objects/pack/pack-68c6c8c8538900694c32380ac1484201c8b60d8d.idx
> 138 ce6131022c3a48a15f4b7a68afb6ecf3b3bcb0cd (03c2fd95)
> 12 d1ff1c9224ae5e58a7656fb9ecc95865d42ed71e (64dd3dba)
> 183 df967b96a579e45a18b8251732d16804b2e56a55 (879729b5)
> ./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index <.git/objects/pack/pack-8f53f837597ebbdfc6f8ed173349e5cecbcfb97e.idx
> 12 ad16bed54cc61cf036075879deeff95ae977514b (239ee6ff)
> ./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index <.git/objects/pack/pack-b8dc9aadaadc12c82b0053fdee0039ae1025a8f8.idx
> 12 4f336f3df31054eabc05ac05f98bc024c8e05423 (24bc6ce2)
> ./trash directory.t7704-repack-cruft/max-cruft-size-prune: git show-index <.git/objects/pack/pack-c2357b2b204fda52bc1f5515de94227e1db012af.idx
> 12 bd44d8aa2d22eb47ff70cef4b0bb45d1549ee49c (c2c93868)

OK, so it looks like the first repack is doing what we expect: presumably the first pack containing three objects holds the result of "test_commit base" (and contains the blob, tree, and commit objects for commit "base"). Then I'm assuming that the remaining three packs hold $foo, $bar, and $baz in some unspecified order.

So I think that everything up through the first repack is doing the right thing.

(As an aside, it took me a while to remember what was going on with this test. Since it was confusing to me as its author, I figured it may be helpful to spell out some of the details. We're just making sure that pruning a cruft object works with multiple cruft packs, and we're adjusting the mtimes of the *.mtimes files themselves to ensure that they are rewritten during the pruning repack. Those adjustments have no bearing on what actually gets pruned, unlike when we update the mtime of the loose copy of $foo, which does affect pruning).

Anyway... in your setup it looks like all three objects are gone, and we expected only $foo to be pruned. So I suspect what's going on is that this test takes longer than 10 seconds to run on your machine, in which case it would fail as all objects would have passed the 10-second grace period.

If you apply:

--- 8< ---

diff --git a/t/t7704-repack-cruft.sh b/t/t7704-repack-cruft.sh
index 71e1ef3a10..959e6e2648 100755
--- a/t/t7704-repack-cruft.sh
+++ b/t/t7704-repack-cruft.sh
@@ -330,7 +330,7 @@ test_expect_success '--max-cruft-size with pruning' '
 		# repack (and prune) with a --max-cruft-size to ensure
 		# that we appropriately split the resulting set of packs
 		git repack -d --cruft --max-cruft-size=1M \
-			--cruft-expiration=10.seconds.ago &&
+			--cruft-expiration=1000.seconds.ago &&
 		ls $packdir/pack-*.mtimes | sort >cruft.after &&

 		for cruft in $(cat cruft.after)
--- >8 ---

, does it still fail?

(There's really no reason to have --cruft-expiration as short as 10
seconds here, since we backdate the cruft mtimes by 10,000 seconds.)

Thanks,
Taylor