Re: [PATCH] enable core.fsyncObjectFiles by default

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 20, 2018, 22:27 UTC
Message-ID: <xmqqefmknp3f.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20180120221445.GA4451@thunk.org>

Theodore Ts'o <tytso@mit.edu> writes:

> ....  I've never been fond of the "git repack -A" behavior
> where it can generate huge numbers of loose files.  I'd much prefer it
> if the other objects ended up in a separate pack file, and then some
> other provision made for nuking that pack file some time later....

Yes, a "cruft pack" that holds unreachable object has been discussed a few times recently on list, and I do agree that it is a desirable thing to have in the longer run.

What's tricky is to devise a way to allow us to salvage objects that are placed in a cruft pack because they are accessed recently, proving themselves to be no longer crufts. It could be that a good way to resurrect them is to explode them to loose form when they are accessed out of a cruft pack. We need to worry about interactions with read-only users if we go that route, but with the current "explode unreachable to loose, touch their mtime when they are accessed" scheme ends up ignoring accesses from read-only users that cannot update mtime, so it might not be too bad.