Re: [PATCH 15/16] promisor-remote: auto-configure unknown remotes

[Patrick Steinhardt <ps@pks.im>]

On Mon, Mar 23, 2026 at 09:05:18AM +0100, Christian Couder wrote:
> Previous commits have introduced the `promisor.acceptFromServerUrl`
> config variable to whitelist some URLs advertised by a server through
> the "promisor-remote" protocol capability.
> 
> However the new `promisor.acceptFromServerUrl` mechanism, like the old
> `promisor.acceptFromServer` mechanism, still requires a remote to
> already exist in the client's local configuration before it can be
> accepted. This places a significant manual burden on users to
> pre-configure these remotes, and creates friction for administrators
> who have to troubleshoot or manually provision these setups for their
> teams.
> 
> To eliminate this burden, let's automatically create a new `[remote]`
> section in the client's config when a server advertises an unknown
> remote whose URL matches a `promisor.acceptFromServerUrl` glob pattern.

Would it make sense to extend git-clone(1) to have a command line option
that basically does this as a one-shot? Something like `git clone
--accept-promisors=url:https://gitlab.com/*`? I assume that many users
may not want to keep on updating their configured promisors all the
time.

Furthermore, this here reconfirms my thought on the previous commit that
it would make sense to detangle accepting promisors, storing them in the
configuration and updating them automatically. These are all different
things:

  - Accepting promisors is basically an ongoing runtime thing where you
    start to use announced promisors even though they are not configured
    at all.

  - Storing promisors is typically a one-time thing that you'd want to
    do when creating a new repository.

  - Updating promisors automatically is probably something you want to
    do on an ongoing basis when you have stored promisors.

We're currently putting all of these use cases into the same bag, but
they have very different characteristics. I guess the most common use
case will eventually be to never auto-accept promisors, store them at
clone time, and keep them updated whenever they change. This cannot be
expressed with "promisor.acceptFromServerUrl" as far as I understand.

So ideally, we'd have:

  - "acceptFromServer" to configure ongoing runtime behaviour.

  - "storeFromServer" and a one-time command-line option for
    git-clone(1) to configure which remotes to persist.

  - "updateFromServer" to update stored promisors.

Patrick