On Thu, May 14, 2020 at 3:05 PM Caleb Gray <hey@xxxxxxxxxxxxx> wrote: > > 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. I don't know that such an approach would ever get accepted. At most it could only be a partial replica of a `.get` directory. For example, including `.git/config` or `.git/hooks` carries some heavy security considerations that make it very unlikely such a change would get accepted. When you pare down the things from the `.git` directory that can reasonably be included, I suspect you're pretty much going to be left with `.git/objects/pack/pack-<something>.pack`, and perhaps `.git/packed-refs` (although the ref negotiations the client needs to do in order to even request a pack means you're unlikely to actually _benefit_ from including `packed-refs`). For such client-side caching, really you may be better of not trying to reinvent the wheel and instead, as others have suggested, simply use `git clone --reference` (possibly plus `--dissociate` if you don't want any long-term connection between clones) to allow `git clone` to reference all the objects you have available locally to skip most of the pack transfer. If you do this, then `git clone` can _already_ make use of local `idx` files, in addition to packs, to save work. Bryan Turner
