# Summary Allowing for Git client and server to exchange information through the protocol. This will allow for multiple things. 1. server and client can agree on using a common promisor remote (this is what https://gitlab.com/gitlab-org/git/-/issues/421 is about) 2. server can tell the client which promisor remote to use 3. server can pass an authentication token to the client for fetching from the promisor remote After https://gitlab.com/gitlab-org/git/-/issues/421, so step 1. above, is done, we can use the new "promisor-remote" capability added by that step to pass more information, like the authentication token through this capability (step 3.), and we can add a config option (or modify an existing one) so that the client actually uses the promisor remote information it is passed to connect to the right promisor remote (step2.). ### Business case One of the most important problems that Git has in the context of monorepos is the introduction of binary files. While tools like Git LFS exist, they aren't a great user experience and require third-party tooling. Furthermore, Git LFS cannot be used to strip binary files out of the history of Git and move them elsewhere. The introduction of a native replacement for Git LFS will allow us to reap benefits on the client- and server-side: - Clients can fetch objects on demand more readily, without requiring Git LFS and without requiring history rewrites. - Servers can offload blobs to secondary (and cheaper) storage and serve them via CDNs. These are necessary building blocks to make Git repositories ready to host large binary files as part of their commit history and will thus open up new industries that heavily rely on binary files. Furthermore, offloading large binary files to secondary storage may allow us to significantly reduce cost and reduce load on the Gitaly nodes, thus ensuring that GitLab.com can scale. ### Exit criteria The server can advertise a promisor remote's name, URL, filter and token, to the client. The client can use the URL and filter it didn't know about to fetch objects at clone time from the remote. ### Status <!-- STATUS NOTE START --> ## Status 2026-02-19 :clock1: **total hours spent this week by all contributors**: 16 :tada: **achievements**: - Released as part of Git v2.49.0 on March 14, 2025: [The server can pass a name and an URL to the client for each promisor remote it wants to advertise.](https://lore.kernel.org/git/20250218113204.2847463-1-christian.couder@gmail.com/) - Released as part of Git v2.52.0 on Nov 17, 2025: [The server can additionally pass a filter and a token for each promisor remote it wants to advertise.](https://lore.kernel.org/git/20250908053056.956907-1-christian.couder@gmail.com/) - After the [v2 patch series](https://lore.kernel.org/git/20260204110818.2919273-1-christian.couder@gmail.com/) patch series got reviewed, I worked on a [v3 series](https://lore.kernel.org/git/20260212100843.883623-1-christian.couder@gmail.com/), sent it, and worked on a [v4 series](https://lore.kernel.org/git/20260216132317.15894-1-christian.couder@gmail.com/) as a small issue was found in the v3. The v4 got merged to the 'next' branch and should be merged to 'master' soon. The series implements a new `promisor.storeFields` config variable and an `auto` mode for `git clone --filter=<filter-spec>` and `git fetch --filter=<filter-spec>`. They allow a client to access promisor remotes without much configuration by just using the information they get from the server. :issue-blocked: **blockers**: - During February, I am still working at 50% for the Contributor Success team to finish some work for that team. :arrow_forward: **next**: - We have not yet decided what will go next. I will likely work on making the client accept URLs and new remotes in general from the server, even though it could be seen as risky security wise on the mailing list. _Copied from https://gitlab.com/groups/gitlab-org/-/epics/15972#note_3095936732_ <!-- STATUS NOTE END -->