git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: rsbecker@nexbridge.com
Cc: git@vger.kernel.org
Subject: Re: [BUG] 2.46.0 t7701.09 fails on NonStop ia64
Date: Sun, 4 Aug 2024 14:12:38 -0400	[thread overview]
Message-ID: <Zq/ElpJpbcUqB+4e@nand.local> (raw)
In-Reply-To: <04f101dae68c$c57574b0$50605e10$@nexbridge.com>

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.)

Thanks,
Taylor

  reply	other threads:[~2024-08-04 18:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-01 18:03 [BUG] 2.46.0 t7701.09 fails on NonStop ia64 rsbecker
2024-08-01 19:23 ` Taylor Blau
2024-08-01 22:25   ` rsbecker
2024-08-02  0:58     ` Taylor Blau
2024-08-02  1:51       ` rsbecker
2024-08-02 22:07       ` rsbecker
2024-08-04 16:02         ` Taylor Blau
2024-08-04 16:15           ` rsbecker
2024-08-04 16:19             ` Taylor Blau
2024-08-04 16:38               ` rsbecker
2024-08-04 18:12                 ` Taylor Blau [this message]
2024-08-04 19:15                   ` rsbecker

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=Zq/ElpJpbcUqB+4e@nand.local \
    --to=me@ttaylorr.com \
    --cc=git@vger.kernel.org \
    --cc=rsbecker@nexbridge.com \
    /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;
as well as URLs for NNTP newsgroup(s).