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

From: Bryan Turner <bturner@atlassian.com>
Date: May 14, 2020, 22:44 UTC
Message-ID: <CAGyf7-Fvyes2AwPhqAz=GhpDb=P664DLpK+4o3-ChKyR5KmJQw@mail.gmail.com>
In-Reply-To: <CAGjfG9akT+KG-tttRWEX_ZqxrqPoY_4Ed7Pymt4DkV5Rgc1CEA@mail.gmail.com>

On Thu, May 14, 2020 at 3:05 PM Caleb Gray <hey@calebgray.com> wrote:

Show 8 quoted lines

>
> 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