# 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-10-01 :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. - Released as part of Git v2.56.0 on September 27, 2026: 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`. It is not very friendly and error prone to have to manage this using an environment variable. - 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 have been working on [a different approach (based on a protected `uploadpack.lazyFetchTrusted` configuration variable)](https://gitlab.com/gitlab-org/git/-/merge_requests/643) that seems to have been accepted: - [v1 (2026-08-07)](https://lore.kernel.org/git/20260807135511.1818458-1-christian.couder@gmail.com/) - [v2 (2026-08-13)](https://lore.kernel.org/git/20260813154748.2378747-1-christian.couder@gmail.com/) - [v3 (2026-09-08)](https://lore.kernel.org/git/20260908164129.560396-1-christian.couder@gmail.com/) - [v4 (2026-09-28)](https://lore.kernel.org/git/20260928133846.2094261-1-christian.couder@gmail.com/) - [v5 (2026-10-02)](https://lore.kernel.org/git/20261002082322.2682869-1-christian.couder@gmail.com/) - The changes in v4 and v5 (that I sent this week) are very small, so this is likely to be merged soon. - 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 one new team member recently joined us 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 and leave that for later. _Copied from https://gitlab.com/groups/gitlab-org/-/epics/15972#note_3934191595_ <!-- STATUS NOTE END -->