On 2025-02-11 at 22:38:36, Brian Celenza wrote: > Hey all, > > I’m working on a project that uses git bundles and the bundle-uri server capability and had a question about how this works with the git protocol. > > The goal: advertise a specific bundle-url depending on the type of clone (e.g., full or filtered) requested by the client. > > Context: When the client attempts to clone from a server that advertises bundle-uris, there is currently a strict ordering of the operations that occurs, namely: > Capability advertisements from the server (including `bundle-uri`) and client > `ls-refs` command sent by the client > `bundle-uri` command sent by the client (if enabled) > `fetch` command sent by the client with options (e.g. `filter blob:none`) > > Overall, the command ordering makes sense: to know what to `fetch` from the origin server, the client needs to download and extract the bundle first. However, if the server wants to send the bundle that best fits the client's intent, it must guess what that intent will be, which may result in the client receiving more in the bundle than was intended. > > Because the fetch command occurs after the bundle-uri command by the client, the server does not have the opportunity to provide the client with a bundle-uri that’s a best match for the filter options it will eventually tell the server about in the follow-up `fetch` command. > > The question: am I missing something, or is this just the current behavior of the git protocol? If the latter, is there any similar prior art for how a client could provide the server with some form of hint about its intent (e.g., “I intend to fetch with this filter or depth”) ahead of the `bundle-uri` command? I've just read the protocol, and I think it's pretty clear that it doesn't take any options, so we'd probably need to add a capability extension to support that. The syntax of the command is in theory capable of supporting parameters, it just doesn't have any now. My guess is that it's because this functionality doesn't see a huge amount of use. However, I don't think it should be a problem to add support for this in the future if someone wanted to. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
