On 11/29/2021 5:25 PM, Taylor Blau wrote: > +Notable alternatives to this design include: > + > + - The location of the per-object mtime data, and > + - Whether cruft packs should be incremental or not. It was not obvious from this sentence that "incremental" meant that we could store a number of cruft packs and use the mtime of each pack as the time for all contained objects. > +On the location of mtime data, a new auxiliary file tied to the pack was chosen > +to avoid complicating the `.idx` format. If the `.idx` format were ever to gain > +support for optional chunks of data, it may make sense to consolidate the > +`.mtimes` format into the `.idx` itself. > + > +Incremental cruft packs (i.e., where each time a repository is repacked a new > +cruft pack is generated containing only the unreachable objects introduced since > +the last time a cruft pack was written) are significantly more complicated to > +construct, and so aren't pursued here. The obvious drawback to the current > +implementation is that the entire cruft pack must be re-written from scratch. But you seem to be pointing that direction here. The difference being that you don't discuss how a list of cruft packs could avoid the .mtimes file. I think what is hidden underneath "significantly more complicated to construct" are situations such as "this object was in an old cruft pack, but then became reachable, but now is unreachable again". I'll try to remember to come back to this after seeing the situations you cover in your tests. Thanks, -Stolee
