On Tue, Apr 18, 2023 at 06:56:22AM -0400, Jeff King wrote: > On Mon, Apr 17, 2023 at 04:54:36PM -0400, Taylor Blau wrote: > > > We could run this test twice, once with `--cruft` and once with > > `--no-cruft`, but doing so is unnecessary, since the object rescuing and > > freshening behavior is already extensively tested via t5329. > > That's doubtless true for the general case of freshening (after all, > that's the point of cruft packs). I do wonder about these "broken links" > cases: > > > @@ -151,7 +151,7 @@ test_expect_success 'do not complain about existing broken links (commit)' ' > > some message > > EOF > > commit=$(git hash-object -t commit -w broken-commit) && > > - git gc -q 2>stderr && > > + git gc --no-cruft -q 2>stderr && > > verbose git cat-file -e $commit && > > test_must_be_empty stderr > > ' > > The idea is that we don't complain when repacking unreachable-but-broken > segments of history. Which could perhaps behave differently for objects > that are going into a cruft pack versus being turned loose. So maybe > it's worth covering for the --cruft case, too. I dunno. I think we already have coverage of those cases in t5329, specifically in the tests: - cruft packs tolerate missing trees (expire $expire) - cruft packs tolerate missing blobs (expire $expire) which are tested for both the pruning and non-pruning implementations (by setting $expire to "2.weeks.ago", and "never", respectively). Thanks, Taylor
