From: Jeff King <firstname.lastname@example.org> To: Eric Wong <email@example.com> Cc: "Ævar Arnfjörð Bjarmason" <firstname.lastname@example.org>, email@example.com, "Junio C Hamano" <firstname.lastname@example.org> Subject: Re: dumb HTTP things I want to do Date: Tue, 14 May 2019 08:27:30 -0400 [thread overview] Message-ID: <20190514122730.GB27276@sigill.intra.peff.net> (raw) In-Reply-To: <20190514121350.jugxtegpvcxr4vjs@dcvr> 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@sigill.intra.peff.net/ > 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
next prev parent reply other threads:[~2019-05-14 12:27 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-11 1:34 [PATCH] update-server-info: avoid needless overwrites Eric Wong 2019-05-11 7:35 ` Eric Sunshine 2019-05-11 20:47 ` [PATCH v2] " Eric Wong 2019-05-11 21:17 ` [PATCH] " Eric Wong 2019-05-11 23:37 ` Ævar Arnfjörð Bjarmason 2019-05-12 0:38 ` Eric Wong 2019-05-12 4:08 ` Jeff King 2019-05-12 7:16 ` Ævar Arnfjörð Bjarmason 2019-05-14 9:47 ` Jeff King 2019-05-14 10:33 ` Ævar Arnfjörð Bjarmason 2019-05-14 11:24 ` Jeff King 2019-05-14 11:57 ` Ævar Arnfjörð Bjarmason 2019-05-14 11:50 ` Eric Wong 2019-05-14 12:13 ` dumb HTTP things I want to do Eric Wong 2019-05-14 12:27 ` Jeff King [this message] 2019-05-14 12:19 ` [PATCH] update-server-info: avoid needless overwrites Ævar Arnfjörð Bjarmason 2019-05-14 12:29 ` Jeff King 2019-05-15 0:45 ` [PATCH 2/1] server-info: conditionally update on fetch Eric Wong 2019-05-15 20:38 ` [WIP] repack leaving stale entries in objects/info/packs Eric Wong 2019-05-15 21:48 ` Jeff King 2019-05-23 8:59 ` [PATCH] server-info: do not list unlinked packs Eric Wong 2019-05-23 10:24 ` Jeff King 2019-05-23 17:27 ` [PATCH v2] " Eric Wong 2019-05-24 6:05 ` Jeff King 2019-05-24 7:34 ` Ævar Arnfjörð Bjarmason 2019-05-13 23:17 ` [PATCH v3] update-server-info: avoid needless overwrites Eric Wong
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190514122730.GB27276@sigill.intra.peff.net \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: dumb HTTP things I want to do' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).