On Tue, May 14, 2019 at 12:13:50PM +0000, Eric Wong wrote:
> I'm not sure when/if I'll have time for this; but this ought to
> be possible:
>
> GIT_DIR=$HTTP_URL git <any read-only command>
>
> And possible without existing admins to setup or change
> anything on their server.
> [...]
> git doesn't need mmap; and curl + Range requests ought to be
> able to get us what we need to emulate pread. It'd be great for
> low-latency LANs, maybe not so great with high latency; but
> probably better in many cases than cloning a giant repo to cat
> one blob.
My first thought here is that we could probably just use the filesystem
boundary as the appropriate layer, and have an httpfs fuse driver. Your
mention of fusedav makes me think you've already gone this route.
I guess non-dav http doesn't necessarily let us enumerate directories.
But it might be enough if we could insert ourselves in a few key spots.
E.g., when we try to opendir("objects/packs") and it fails with ENOSYS
or similar, then we fallback to opening "objects/info/packs" to get the
same information (and ditto for loose ref traversal).
There'd still be _some_ work in Git, but it wouldn't require replacing
every single read with HTTP magic.
> Also, cloning on a static bundle ought to be doable with:
>
> git clone $REMOTE_OR_LOCAL_PATH/foo.bundle
Some nearby discussion:
https://public-inbox.org/git/20190514092900.GA11679@xxxxxxxxxxxxxxxxxxxxx/
> And yeah, it also sucks that bundles double storage overhead
> for admins; it would be nice if I could use bundles as alternates
> or packs...
Yes. It's nice that they're a single file for some uses, but in terms of
implementation it would be easier if the bundle files just said "here
are some refs, and you can find my packfile in the relative filename
XYZ.pack". And then you'd just store the two of them together (and a
matching .idx if you wanted to use it as a real pack, but the bundle
readers wouldn't care).
It probably wouldn't be that hard to wedge that into the bundle format
by bumping the version field.
-Peff
