From: Junio C Hamano <gitster@pobox.com>
To: Christian Couder <christian.couder@gmail.com>
Cc: git@vger.kernel.org, Patrick Steinhardt <ps@pks.im>
Subject: Re: [PATCH] promisor-remote: fix crash without a repository
Date: Fri, 13 Nov 2026 11:42:47 -0800 [thread overview]
Message-ID: <xmqq33t4bjrc.fsf@gitster.g> (raw)
In-Reply-To: <20261113000600.202744-2-christian.couder@gmail.com> (Christian Couder's message of "Fri, 13 Nov 2026 01:06:01 +0100")
Christian Couder <christian.couder@gmail.com> writes:
> When `git ls-remote` is run outside a repo with some promisor remote
> related config options that make it write to its config, namely:
>
> - "promisor.acceptFromServerUrl", which makes it auto-create a
> remote, or
> - "promisor.acceptFromServer" with "promisor.storeFields", which
> makes it store fields,
>
> it crashes in configure_auto_promisor_remote() or store_one_field(), as
> the `repo` argument passed to these functions has its `gitdir` member
> set to NULL.
It is tricky that "ls-remote" wants to work outside a repository.
> This has been happening since 3e20258d11 (promisor-remote: allow a
> client to store fields, 2026-02-16) for the `storeFields` case, and
> since 7a56394fc6 (promisor-remote: auto-configure unknown remotes,
> 2026-05-27) for the auto-creation case.
>
> Let's fix that by checking if `repo->gitdir` is NULL at the beginning
> of filter_promisor_remote() and returning from it right away in that
> case. It doesn't make sense to further process the promisor remote
> advertisement as `git ls-remote` currently has no use for promisor
> remotes anyway.
Another possibility is to nip this higher in the callchain. If we
know, as you said, "ls-remote" has no need to talk about promisors,
turning promisor_remote_reply() into a NOOP outside a repository
might be better, but the function does not take a repository
parameter to be able to tell if we have a repository in the first
place---perhaps we should add one? An illustration patch below.
The callers (there are only two) should of course be updated.
In any case, we should comment and say why we punt when '.gitdir' is
NULL and why it is safe to punt. In the illustration patch below,
I only covered the former but not the latter.
promisor-remote.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git c/promisor-remote.c w/promisor-remote.c
index 316d9950aa..702c53c2c4 100644
--- c/promisor-remote.c
+++ w/promisor-remote.c
@@ -1373,11 +1373,20 @@ static void filter_promisor_remote(struct repository *repo,
}
}
-void promisor_remote_reply(const char *info, char **accepted_out)
+void promisor_remote_reply(struct repository *repo, const char *info, char **accepted_out)
{
struct string_list accepted_remotes = STRING_LIST_INIT_NODUP;
- filter_promisor_remote(the_repository, &accepted_remotes, info);
+ /*
+ * "ls-remote" has no business talking about promisors, and worse yet,
+ * it can be run outside a repository.
+ */
+ if (!repo->gitdir) {
+ if (accepted_out)
+ *accepted_out = NULL;
+ return;
+ }
+ filter_promisor_remote(repo, &accepted_remotes, info);
if (accepted_out) {
if (accepted_remotes.nr) {
prev parent reply other threads:[~2026-11-13 19:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-13 0:06 [PATCH] promisor-remote: fix crash without a repository Christian Couder
2026-11-13 19:42 ` Junio C Hamano [this message]
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=xmqq33t4bjrc.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
/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