On Tue, Feb 18, 2025 at 12:32:01PM +0100, Christian Couder wrote: > This work is part of some effort to better handle large files/blobs in > a client-server context using promisor remotes dedicated to storing > large blobs. To help understand this effort, this series now contains > a patch (patch 6/6) that adds design documentation about this effort. > > Last year, I sent 3 versions of a patch series with the goal of > allowing a client C to clone from a server S while using the same > promisor remote X that S already use. See: > > https://lore.kernel.org/git/20240418184043.2900955-1-christian.couder@xxxxxxxxx/ > > Junio suggested to implement that feature using: > > "a protocol extension that lets S tell C that S wants C to fetch > missing objects from X (which means that if C knows about X in its > ".git/config" then there is no need for end-user interaction at all), > or a protocol extension that C tells S that C is willing to see > objects available from X omitted when S does not have them (again, > this could be done by looking at ".git/config" at C, but there may be > security implications???)" > > This patch series implements that protocol extension called > "promisor-remote" (that name is open to change or simplification) > which allows S and C to agree on C using X directly or not. > > I have tried to implement it in a quite generic way that could allow S > and C to share more information about promisor remotes and how to use > them. > > For now, C doesn't use the information it gets from S when cloning. > That information is only used to decide if C is OK to use the promisor > remotes advertised by S. But this could change in the future which > could make it much simpler for clients than using the current way of > passing information about X with the `-c` option of `git clone` many > times on the command line. > > Another improvement could be to not require GIT_NO_LAZY_FETCH=0 when S > and C have agreed on using S. I'm fine with this version of the patch series. There are a couple of features that we probably want to have eventually: - Persisting announced promisors. As far as I understand, we don't yet write them into the client-side configuration of the repository at all. - Promisor remote agility. When the set of announced promisors changes, we should optionally update the set of promisors connected to that remote on the client-side. - Authentication. In case the promisor remote requires authentication we'll somehow need to communicate the credentials to the client. All of these feel like topics that can be implemented incrementally once the foundation has landed, so I don't think they have to be implemented as part of the patch series here. I also don't see anything obvious that would block any of these features with the current design. Thanks for working on this! Patrick
