From: Patrick Steinhardt <ps@pks.im>
To: Christian Couder <christian.couder@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Taylor Blau <me@ttaylorr.com>,
Karthik Nayak <karthik.188@gmail.com>,
Elijah Newren <newren@gmail.com>,
Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [PATCH 01/16] promisor-remote: try accepted remotes before others in get_direct()
Date: Thu, 26 Mar 2026 13:20:41 +0100 [thread overview]
Message-ID: <acUklLd07f04wOYi@pks.im> (raw)
In-Reply-To: <20260323080520.887550-2-christian.couder@gmail.com>
On Mon, Mar 23, 2026 at 09:05:04AM +0100, Christian Couder wrote:
> When a server advertises promisor remotes and the client accepts some
> of them, those remotes carry the server's intent: 'fetch missing
> objects preferably from here', and the client agrees with that for the
> remotes it accepts.
>
> However promisor_remote_get_direct() actually iterates over all
> promisor remotes in list order, which is the order they appear in the
> config files (except perhaps for the one appearing in the
> `extensions.partialClone` config variable which is tried last).
>
> This means an existing, but not accepted, promisor remote, could be
> tried before the accepted ones, which does not reflect the intent of
> the agreement between client and server.
>
> If the client doesn't care about what the server suggests, it should
> accept nothing and rely on its remotes as they are already configured.
>
> To better reflect the agreement between client and server, let's make
> promisor_remote_get_direct() try the accepted promisor remotes before
> the non-accepted ones.
Interesting, and it feels sensible to me. Is it documented anywhere that
the ordering of announced remotes is actually important?
> Concretely, let's extract a try_promisor_remotes() helper and call it
> twice from promisor_remote_get_direct():
>
> - first with an `accepted_only=true` argument to try only the accepted
> remotes,
> - then with `accepted_only=false` to fall back to any remaining remote.
>
> Ensuring that accepted remotes are preferred will be even more
> important if in the future a mechanism is developed to allow the
> client to auto-configure remotes that the server advertises. This will
> in particular avoid fetching from the server (which is already
> configured as a promisor remote) before trying the auto-configured
> remotes, as these new remotes would likely appear at the end of the
> config file, and as the server might not appear in the
> `extensions.partialClone` config variable.
Not quite sure I correctly understand this paragraph. Is the idea that
in the future, we might not even store announced promisors in the config
at all but simply use whatever the server announces on any given fetch?
> diff --git a/promisor-remote.c b/promisor-remote.c
> index 96fa215b06..3f8aeee787 100644
> --- a/promisor-remote.c
> +++ b/promisor-remote.c
> @@ -268,11 +268,37 @@ static int remove_fetched_oids(struct repository *repo,
> return remaining_nr;
> }
>
> +static int try_promisor_remotes(struct repository *repo,
> + struct object_id **remaining_oids,
> + int *remaining_nr, int *to_free,
> + bool accepted_only)
> +{
> + struct promisor_remote *r = repo->promisor_remote_config->promisors;
> +
> + for (; r; r = r->next) {
> + if (accepted_only && !r->accepted)
> + continue;
> + if (!accepted_only && r->accepted)
> + continue;
This can be simplified to `if (!accepted_only != !r->accepted)`.
Also, can we maybe add a test for this to verify that we use the correct
ordering now?
Patrick
next prev parent reply other threads:[~2026-03-26 12:20 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-23 8:05 [PATCH 00/16] Auto-configure advertised remotes via URL whitelist Christian Couder
2026-03-23 8:05 ` [PATCH 01/16] promisor-remote: try accepted remotes before others in get_direct() Christian Couder
2026-03-26 12:20 ` Patrick Steinhardt [this message]
2026-03-23 8:05 ` [PATCH 02/16] urlmatch: change 'allow_globs' arg to bool Christian Couder
2026-03-23 8:05 ` [PATCH 03/16] urlmatch: add url_is_valid_pattern() helper Christian Couder
2026-03-26 12:20 ` Patrick Steinhardt
2026-03-23 8:05 ` [PATCH 04/16] promisor-remote: clarify that a remote is ignored Christian Couder
2026-03-26 12:20 ` Patrick Steinhardt
2026-03-23 8:05 ` [PATCH 05/16] promisor-remote: refactor has_control_char() Christian Couder
2026-03-23 8:05 ` [PATCH 06/16] promisor-remote: refactor accept_from_server() Christian Couder
2026-03-23 8:05 ` [PATCH 07/16] promisor-remote: keep accepted promisor_info structs alive Christian Couder
2026-03-26 12:21 ` Patrick Steinhardt
2026-03-23 8:05 ` [PATCH 08/16] promisor-remote: remove the 'accepted' strvec Christian Couder
2026-03-26 12:21 ` Patrick Steinhardt
2026-03-23 8:05 ` [PATCH 09/16] promisor-remote: add 'local_name' to 'struct promisor_info' Christian Couder
2026-03-26 12:21 ` Patrick Steinhardt
2026-03-23 8:05 ` [PATCH 10/16] promisor-remote: pass config entry to all_fields_match() directly Christian Couder
2026-03-26 12:21 ` Patrick Steinhardt
2026-03-23 8:05 ` [PATCH 11/16] promisor-remote: refactor should_accept_remote() control flow Christian Couder
2026-03-26 12:21 ` Patrick Steinhardt
2026-03-23 8:05 ` [PATCH 12/16] t5710: use proper file:// URIs for absolute paths Christian Couder
2026-03-26 12:21 ` Patrick Steinhardt
2026-03-23 8:05 ` [PATCH 13/16] promisor-remote: introduce promisor.acceptFromServerUrl Christian Couder
2026-03-26 12:21 ` Patrick Steinhardt
2026-03-23 8:05 ` [PATCH 14/16] promisor-remote: trust known remotes matching acceptFromServerUrl Christian Couder
2026-03-23 18:54 ` Junio C Hamano
2026-03-23 23:47 ` Junio C Hamano
2026-03-27 12:17 ` Christian Couder
2026-03-26 12:21 ` Patrick Steinhardt
2026-03-23 8:05 ` [PATCH 15/16] promisor-remote: auto-configure unknown remotes Christian Couder
2026-03-26 12:21 ` Patrick Steinhardt
2026-03-23 8:05 ` [PATCH 16/16] doc: promisor: improve acceptFromServer entry Christian Couder
2026-03-26 12:21 ` [PATCH 00/16] Auto-configure advertised remotes via URL whitelist Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=acUklLd07f04wOYi@pks.im \
--to=ps@pks.im \
--cc=chriscool@tuxfamily.org \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=karthik.188@gmail.com \
--cc=me@ttaylorr.com \
--cc=newren@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox