# 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-03-12 :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/) - The [v4 patch series](https://lore.kernel.org/git/20260216132317.15894-1-christian.couder@gmail.com/) got merged to the 'master' branch. It 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**: - This week I have continued working on a new `promisor.acceptFromServerUrl` configuration variable to allow clients to accept new promisor remotes (see https://gitlab.com/gitlab-org/git/-/work_items/423). I expect to send a first version to the Git mailing list soon. - In February, I was still working at 50% for the Contributor Success team, and there are still related things I need to finish. :arrow_forward: **next**: - After making the client accept URLs and new remotes in general from the server (https://gitlab.com/gitlab-org/git/-/work_items/423), there might be some polishing to do, like not requiring `GIT_NO_LAZY_FETCH=0` to allow lazy fetching. _Copied from https://gitlab.com/groups/gitlab-org/-/epics/15972#note_3152610980_ <!-- STATUS NOTE END -->