# Summary Allowing for Git client and server to exchange information through the protocol. This opens up many possibilities. A new "promisor-remote" protocol capability has been implemented in several steps: 1. **Client and server can agree on using a common promisor remote** ([#421](https://gitlab.com/gitlab-org/git/-/issues/421), [#509](https://gitlab.com/gitlab-org/git/-/issues/509), [#332](https://gitlab.com/gitlab-org/git/-/issues/332)) - :white_check_mark: Released in `Git v2.49.0` (March 2025). The server can advertise a name and URL for each promisor remote. 2. **Server can pass a token and a filter to the client** ([#422](https://gitlab.com/gitlab-org/git/-/issues/422)) - :white_check_mark: Released in `Git v2.52.0` (November 2025). The server can additionally advertise a filter and a token for each promisor remote. 3. **Client can store and use the token and filter** ([#623](https://gitlab.com/gitlab-org/git/-/issues/623)) - :white_check_mark: Merged to 'next', pending release. A new `promisor.storeFields` config variable and an `auto` mode for `git clone --filter=<filter-spec>` / `git fetch --filter=<filter-spec>` allow the client to use information from the server without much configuration, as long as the promisor remote is already configured on the client. 4. **Server can tell client which new promisor remote to use** ([#423](https://gitlab.com/gitlab-org/git/-/issues/423)) - :construction: Remaining work. The client still cannot accept new promisor remote URLs from the server if they are not already configured locally. This has been postponed due to security concerns, and requires designing secure mechanisms (e.g. URL prefix allowlists) to control which server-advertised remotes the client trusts. ### 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-09-03 :clock1: **total hours spent this week by all contributors**: 2 :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/) - Released as part of Git v2.54.0 on April 20, 2026: [A `promisor.storeFields` config variable and an `--filter=auto` mode for `git clone` and `git fetch`](https://lore.kernel.org/git/20260216132317.15894-1-christian.couder@gmail.com/) allow a client to access promisor remotes without much configuration by just using the information they get from the server. - Merged to `master` but not yet released: A new `promisor.acceptFromServerUrl` configuration variable allows clients to accept new promisor remotes based on url patterns ([part 1](https://lore.kernel.org/git/20260407115243.358642-1-christian.couder@gmail.com/) and [part 2](https://lore.kernel.org/git/20260527140820.1438165-1-christian.couder@gmail.com/)). :issue-blocked: **blockers**: - My current focus is on the GIT_NO_LAZY_FETCH issue: Right now for security reasons when a server cannot lazy fetch when serving a partial clone unless the GIT_NO_LAZY_FETCH environment variable is set to 0. - A few months ago I sent [a small patch series](https://lore.kernel.org/git/20260710085137.4171240-1-christian.couder@gmail.com/), but brian carlson [replied against my patch series](https://lore.kernel.org/git/alFM-4FJQfaEjyju@fruit.crustytoothpaste.net/) for security reasons. - After thinking about this I changed my mind and implemented a different approach that I [sent to the mailing list](https://lore.kernel.org/git/20260807135511.1818458-1-christian.couder@gmail.com/) last week, but with a wrong Signed-off-by trailers in commit messages, and in a way that made the series difficult for Junio to pick-up. I hope someone would still review it, but that didn't happen, and it was marked as "Expecting a reroll." in [Junio's latest "What's cooking in git.git..." email](https://lore.kernel.org/git/xmqqcxvmvda1.fsf@gitster.g/). So I sent [a v2 that fixes the Signed-off-by issue](https://lore.kernel.org/git/20260813154748.2378747-1-christian.couder@gmail.com/) and makes the series easy for Junio to pick-up. Junio reviewed it during my vacation but I did not have time to reply or send a new version yet. I plan to do that soon. - I came back from a 2 week long vacation, so I did not update then. - The fact that the Git team is being reorganized and most team members are now focusing on the Scaling Git effort means that a big share of the regular team work is falling on @toon and me. So that it's difficult to get reviews from team members. That is starting to improve as two new team members recently joined the team though. :arrow_forward: **next**: - Maybe investigate the case where a server could advertised better connected promisor remotes even if it has all the objects. Or we could perhaps just close this epic. _Copied from https://gitlab.com/groups/gitlab-org/-/epics/15972#note_3778657067_ <!-- STATUS NOTE END -->