On Thu, Dec 02, 2021 at 09:33:51AM -0500, Derrick Stolee wrote: > 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. Yes, I think I meant "incremental" in the sense of "incremental commit- graphs". But it's clearer to say "storing unreachable objects in multiple cruft packs" (and then giving an example later on). Thanks! > 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. Yeah, I'm being deliberately vague here, since the aim of this paragraph is to illustrate "this is much more complicated than what we implement here, and the trade-offs are..." Thanks, Taylor
