Re: Add a "Flattened Cache" to `git --clone`?

[Bryan Turner <bturner@atlassian.com>]

On Thu, May 14, 2020 at 3:05 PM Caleb Gray <hey@calebgray.com> 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