From: Junio C Hamano Date: Tue, 29 Jan 2013 22:26:50 GMT Subject: Re: [PATCH 0/2] optimizing pack access on "read only" fetch repos Message-ID: <7vmwvrocb9.fsf@alter.siamese.dyndns.org> In-Reply-To: <20130129211932.GA17377@sigill.intra.peff.net> Jeff King writes: >> > But how do these somewhat mediocre concatenated packs get turned into >> > real packs? >> >> How do they get processed in a fetch-only repositories that >> sometimes run "gc --auto" today? By runninng "repack -a -d -f" >> occasionally, perhaps? > > Do we run "repack -adf" regularly? The usual "git gc" procedure will not > use "-f", and without that, we will not even consider making deltas > between objects that were formerly in different packs (but now are in > the same pack). Correct. It is not a new problem, and while I think it would need some solution, the "coalesce 50 small young packs into one" is not an attempt to address it. > So you are avoiding doing medium-effort packs ("repack -ad") in favor of > doing potentially quick packs, but occasionally doing a big-effort pack > ("repack -adf"). So I think "but occasionally" part is not correct. In either way, the packs use suboptimal delta, and you have to eventually pack with "-f", whether you coalesce 50 packs into 1 often or keep paying the cost of having 50 packs longer. The trade-off is purely between "one potentially quick coalescing per fetch in fetch-only repository" vs "any use of the data in the fetch-only repository (what do they do? build? serving gitweb locally?) has to deal with 25 packs on average, and we still need to pay medium repack cost every 50 fetches".