Actually those are the steps that I'm explicitly hoping can be skipped, both on server and client, after the first successful clone request transaction. The cache itself would be of the end resulting `.git` directory (client side)... unless I have misconceptions about the complexity of reproducing what ends up on the client side from the server side... I figured the shared library probably offers endpoints for the information I'd need to achieve that. On Thu, May 14, 2020 at 2:56 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Caleb Gray <hey@xxxxxxxxxxxxx> writes: > > > To Clarify: I'm talking about a server-side only cache which behaves > > much like a `tar` file: it is a flat version of exactly(*) what ends > > up on the client's storage. When a client runs `git --clone` and > > there's a valid cache on the other end, that's all that gets streamed. > > So this is to save server processing time only. It does not save > bandwidth (the "cache" is bit-for-bit idential replay of the clone > request it served earlier), and it does not save client processing > cycles (as the receiving end must validate the whole packdata it > received before it can even know what objects it received). > > OK. > > > >
