From: Derrick Stolee <derrickstolee@github.com>
Date: Thu, 22 Sep 2022 14:08:05 GMT
Subject: Re: [PATCH 3/7] midx.c: prevent `expire` from removing the cruft pack
Message-ID: <37ffe1a6-bed9-70ce-2c66-b7a2d8c45ba9@github.com>
In-Reply-To: <3ae9903d2df491e291ab975c56ec78aa13d95655.1663638929.git.me@ttaylorr.com>

On 9/19/2022 9:55 PM, Taylor Blau wrote:
> The `expire` sub-command unlinks any packs that are (a) contained in the
> MIDX, but (b) have no objects referenced by the MIDX.

It is important to note that this can only happen if all objects in
the pack have duplicates in other pack-files.
 
> This sub-command ignores `.keep` packs, which remain on-disk even if
> they have no objects referenced by the MIDX. Cruft packs, however,
> aren't given the same treatment: if none of the objects contained in the
> cruft pack are selected from the cruft pack by the MIDX, then the cruft
> pack is eligible to be expired.
> 
> This is less than desireable, since the cruft pack has important

s/desireable/desirable/
(according to my spell-checker)

> metadata about the individual object mtimes, which is useful to
> determine how quickly an object should age out of the repository when
> pruning.
>
> Ordinarily, we wouldn't expect the contents of a cruft pack to
> duplicated across non-cruft packs (and we'd expect to see the MIDX
> select all cruft objects from other sources even less often). But
> nonetheless, it is still possible to trick the `expire` sub-command into
> removing the `.mtimes` file in this circumstance.

I was initially unconvinced that this scenario was super-critical
to keeping the .mtimes file, but I was able to think of cases where
objects are duplicated out of the cruft pack due to de-thinning or
otherwise inefficiently packing unreachable objects into these
other pack-files.

Thanks,
-Stolee