Re: tb/cruft-packs (was Re: What's cooking in git.git (Mar 2022, #01; Thu, 3))

[Taylor Blau <me@ttaylorr.com>]

On Mon, Mar 07, 2022 at 04:25:55PM -0800, Junio C Hamano wrote:
> > If there are other benefits you had in mind, I'm curious to hear them.
> > But I think we should be fine to "lock in" the first version of the
> > .mtimes format since we have an easy-ish mechanism to change it in the
> > future.
>
> Hmph, how?  For example, if it turns out that rewriting .mtimes file
> for each object access turns out to be too much I/O churn and the
> approach to use the mtime of the cruft pack for expiration of the
> entire cruft pack (while ejecting objects that was used from the
> cruft pack out of it to resurrect them from expiration schedule) is
> more preferrable, how do we back out of from the "lock in" once this
> series is unleashed to the workd?

(Note that this series does not propose rewriting the .mtimes file
during each object access, since we only need to update our view of
"last modified time" when pruning or repacking. I think a more complete
explanation of why can be found in [1] and [2]).

That detail aside, if we suddenly decided that cruft packs were a bad
idea and we should get rid of them, then we would be fine to drop all of
the cruft pack code. A future version of Git that didn't understand
cruft packs would ignore the .mtimes file, and we would go back to
handling unreachable objects as we do today (by ejecting them loose when
pruning a too-new object that hasn't fallen out of the grace period).

In other words, this series is designed intentionally so that older
versions of Git that don't understand cruft packs will continue to work
fine even in the presence of cruft packs. If we backed out of cruft
packs at a later date, it would be no different than using an older
version of Git that predates cruft packs.

In other words, I think Stolee's comparison to a feature like
commit-graphs (where older versions of Git that don't yet understand
commit-graphs work just fine even in repositories that have
commit-graphs written) is applicable to this series, too.

Thanks,
Taylor

[1]: https://lore.kernel.org/git/Yap5INmX2ACfjoda@nand.local/
[2]: https://lore.kernel.org/git/YaqCZ7BPwuMGmkZY@nand.local/