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

[<rsbecker@nexbridge.com>]

On Sunday, August 4, 2024 2:13 PM, Taylor Blau wrote:
>On Sun, Aug 04, 2024 at 12:38:38PM -0400, rsbecker@nexbridge.com wrote:
>> ./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.)

This worked. Even taking it down to 100 seconds also works. I suspect that the reason this previously passed was that we have an unrelated heavy use looping process on the box right now so things are taking longer. Running verbose also takes longer.