On Thu, Aug 01, 2024 at 06:25:51PM -0400, rsbecker@xxxxxxxxxxxxx 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
