Re: [PATCH 08/10] t/t6501-freshen-objects.sh: prepare for `gc --cruft` by default

[Taylor Blau <me@ttaylorr.com>]

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