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

[Taylor Blau <me@ttaylorr.com>]

On Thu, Aug 01, 2024 at 06:25:51PM -0400, rsbecker@nexbridge.com wrote:
> ls output with second resolution is here - the file system does not have nanosecond resolution despite showing zeros:
>
> /home/ituglib/randall/git/t/trash directory.t7704-repack-cruft/max-cruft-size-prune/.git/objects/pack: ls -la --full-time
> total 11
> drwxrwxrwx 1 ITUGLIB.RANDALL ITUGLIB 4096 2024-08-01 16:18:55.000000000 -0600 .
> drwxrwxrwx 1 ITUGLIB.RANDALL ITUGLIB 4096 2024-08-01 16:18:48.000000000 -0600 ..
> -r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB 1156 2024-08-01 16:18:52.000000000 -0600 pack-68c6c8c8538900694c32380ac1484201c8b60d8d.idx
> -r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB  217 2024-08-01 16:18:52.000000000 -0600 pack-68c6c8c8538900694c32380ac1484201c8b60d8d.pack
> -r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB   64 2024-08-01 16:18:52.000000000 -0600 pack-68c6c8c8538900694c32380ac1484201c8b60d8d.rev

Ah, I suspect that this is even less interesting than imprecise mtime
resolution. The test expects that the packs are larger than 1M so that
we can exercise writing multiple cruft packs as part of the setup.

But that pack is only 217 bytes, which wouldn't trigger the split. I'm
suspicious that it's even packing the cruft objects at all, so I'm
curious if you can find $foo, $bar, and $baz in the cruft pack's .idx
file(s, if multiple) after the first 'git repack -d --cruft'.

Assuming they are there, it's possible that setting repack.cruftWindow
in the test repository would do the trick.

But I'm suspicious that that's even what's going on since
generate_random_blob()'s first argument is a seed, and all three objects
have different seeds, so I don't think they would even be considered
good delta candidates for one another. But it's also possible that your
generate_random_blob() behaves differently from my own.

Thanks,
Taylor