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

From: Taylor Blau <me@ttaylorr.com>
Date: Mar 8, 2022, 00:49 UTC
Message-ID: <YiaoCivdcT3QE24f@nand.local>
In-Reply-To: <xmqqv8wpp9ws.fsf@gitster.g>

On Mon, Mar 07, 2022 at 04:25:55PM -0800, Junio C Hamano wrote:

Show 12 quoted lines

> > 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/