Subject: Re: [PATCH 00/16] Auto-configure advertised remotes via URL whitelist

From: Patrick Steinhardt <[email-masked]>
Date: Thu, 26 Mar 2026 13:21:48 +0100

On Mon, Mar 23, 2026 at 09:05:03AM +0100, Christian Couder wrote:
> High level description of the patches
> =====================================
> 
>  - Patch 1/16 ("promisor-remote: try accepted remotes before others in
>    get_direct()"):
> 
>    Fixes promisor_remote_get_direct() to prioritize accepted
>    remotes. This could be a separate fix, but is needed towards the
>    end of the series.
> 
>  - Patches 2-3/16 ("urlmatch:*"):
> 
>    Exposes and adapts helpers in the urlmatch API.
> 
>  - Patches 4-11/16 ("promisor-remote:*"):
> 
>    Big refactoring of filter_promisor_remote() and
>    should_accept_remote(). This keeps `struct promisor_info` instances
>    alive longer to anticipate possible state-desync bugs, decouples
>    the server's advertised name from the local config name, and
>    sanitizes control flow without changing the existing behavior.
> 
>  - Patch 12/16 ("t5710:*"):
> 
>    Cleans up how "file://" URIs are managed in the test script to
>    prepare for URI normalization later in the series and avoid issues
>    on Windows.
> 
>  - Patches 13-15/16 ("promisor-remote:*"):
> 
>    The core feature. Introduces the parsing machinery, adds the
>    additive whitelist for known remotes (with url_normalize()
>    security), and finally implements the auto-creation and collision
>    resolution for unknown remotes.
> 
>  - Patch 16/16 ("doc: promisor: improve acceptFromServer entry"):
> 
>    Cleans up and modernizes the existing `promisor.acceptFromServer`
>    documentation.

I wonder whether it would make sense to split up this series into two.
The first 12 patches and parts of 16 are all sensible improvements that
can land independent of the patches that introduce the new logic. And
given that I expect some discussion around the new logic itself, I
expect that these refactorings can land way faster on their own.

It would also help reduce the review load a bit if one then ultimately
only has to review three patches for the new feature.

Patrick