Christian Couder <christian.couder@xxxxxxxxx> writes: > 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. > > Changes compared to version 3 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > - Patches 1/6 and 2/6 are new in this series. They come from the > patch series Usman Akinyemi is working on > (https://lore.kernel.org/git/20250124122217.250925-1-usmanakinyemi202@xxxxxxxxx/). > We need a similar redact_non_printables() function as the one he > has been working on in his patch series, so it's just simpler to > reuse his patches related to this function, and to build on top of > them. Two topics in flight, neither of which hit 'next', sharing a handful of patches is cumbersome to keep track of. Typically our strategy dealing with such a situation has been for these topics to halt and have the authors work together to help the common part solidify a bit better before continuing. Otherwise, every time any one of the topics that share the same early parts of the series needs to change them even a bit, it would result in a huge rebase chaos, and worse yet, even if the two (or more) topics share the need for these two early parts, they may have different dependency requirements (e.g. this may be OK with these two early patches directly applied on 'maint', while the other topic may need to have these two early patches on 'master'). I think [3/6] falls into the same category as [1/6] and [2/6], that is, to lay foundation of the remainder? > - In patch 4/6, the commit message has been improved: > - In patch 4/6, there are also some code changes: > - In patch 4/6, there is also a small change in the tests. All good changes. Will queue, but we should find a better way to manage the "an earlier part is shared across multiple topics" situation. Thanks.
