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? Thanks in advance! Brian
