* Re: [PATCH v2] refspec: safely parse refspecs outside a repository
2026-03-22 2:35 ` [PATCH v2] refspec: safely parse refspecs outside a repository K Jayatheerth
@ 2026-03-22 3:31 ` Junio C Hamano
2026-03-22 3:53 ` Jeff King
` (2 subsequent siblings)
3 siblings, 0 replies; 17+ messages in thread
From: Junio C Hamano @ 2026-03-22 3:31 UTC (permalink / raw)
To: K Jayatheerth; +Cc: git, joliss42, joliss, peff
K Jayatheerth <jayatheerthkulkarni2005@gmail.com> writes:
> Additionally, while looking into the remote-curl execution path,
> take the opportunity to remove an unused `#include "git-curl-compat.h"`
> from `remote-curl.c`.
I wish you didn't do this in the same patch. It is completely
unrelated, isn't it?
> refspec.c | 4 ++--
> remote-curl.c | 1 -
> t/t5551-http-fetch-smart.sh | 15 +++++++++++++++
> 3 files changed, 17 insertions(+), 3 deletions(-)
> +test_expect_success 'ls-remote outside repo does not segfault with fetch refspec' '
> + GIT_CEILING_DIRECTORIES=$(pwd) &&
> + export GIT_CEILING_DIRECTORIES &&
> + mkdir nongit &&
> + (
> + cd nongit &&
> + env GIT_CONFIG_NOSYSTEM=1 \
> + GIT_CONFIG_GLOBAL=/dev/null \
> + GIT_CONFIG_COUNT=1 \
> + GIT_CONFIG_KEY_0=remote.origin.fetch \
> + GIT_CONFIG_VALUE_0="+refs/tags/*:refs/tags/*" \
> + git ls-remote "$HTTPD_URL/smart/repo.git"
This complex "env" dance is probably uncalled for. Wouldn't
something like
mkdir nongit &&
git -C nongit -c remote.origin.fetch=+refs/*:refs/* \
ls-remote "$HTTPD_URL/smart/repo.git"
be sufficient?
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH v2] refspec: safely parse refspecs outside a repository
2026-03-22 2:35 ` [PATCH v2] refspec: safely parse refspecs outside a repository K Jayatheerth
2026-03-22 3:31 ` Junio C Hamano
@ 2026-03-22 3:53 ` Jeff King
2026-03-22 5:36 ` [PATCH v3 1/2] " K Jayatheerth
2026-03-24 1:57 ` [PATCH v4 1/2] remote-curl: fall back to default hash outside repo K Jayatheerth
3 siblings, 0 replies; 17+ messages in thread
From: Jeff King @ 2026-03-22 3:53 UTC (permalink / raw)
To: K Jayatheerth; +Cc: git, joliss42, joliss, gitster
On Sun, Mar 22, 2026 at 08:05:57AM +0530, K Jayatheerth wrote:
> Fix this by ensuring `the_hash_algo` is non-NULL before checking
> `the_hash_algo->hexsz` for both standard and negative refspecs.
> When operating outside a repository, fetching is impossible,
> so bypassing the exact OID check is the cleanest approach.
This argument is glossing over some details. Trying to break down all of
the implications, I think we have:
- Without knowing the hash algo, we cannot reject negative refspecs
that look like oids. This is OK in practice for two reasons. One,
the only commands which apply refspecs are fetch and push, and they
require a repository. And two, while we miss an opportunity to
complain about broken config, it is quite unlikely for somebody to
have such config (a global-level configured negative refspec that
looks like an oid). And they will be told about it when running an
actual fetch anyway.
- Without knowing the hash algo, we cannot mark refspecs with the
exact_sha1 flag. Again, we are not actually applying any refspecs
unless we have a repo. The exact_sha1 flag is used to influence the
set of prefixes we send to a remote v2 upload-pack process, but
only for fetch (which requires a repository). For ls-remote, which
can run outside a repo, we don't even look at the refspecs.
And so for those reasons it's probably OK to quietly ignore things.
Still, it rubs me the wrong way a little that we might create a subtle
bug from some other caller.
If we think we don't care about refspecs, it kind of makes me wonder if
we ought to be able to tell the remote API that we are interested in
remotes for their URLs only, and _not_ for their refspecs. But maybe
that leads to madness, as we end up with half-initialized "struct
remote"s floating around our process.
The other thing I wondered is why we are talking about remote-curl here,
and not ls-remote. And that's because ls-remote already hacked around
this!
Check out 9e89dcb66a (builtin/ls-remote: fall back to SHA1 outside of a
repo, 2024-08-02), which adds this:
/*
* TODO: This is buggy, but required for transport helpers. When a
* transport helper advertises a "refspec", then we'd add that to a
* list of refspecs via `refspec_append()`, which transitively depends
* on `the_hash_algo`. Thus, when the hash algorithm isn't properly set
* up, this would lead to a segfault.
*
* We really should fix this in the transport helper logic such that we
* lazily parse refspec capabilities _after_ we have learned about the
* remote's object format. Otherwise, we may end up misparsing refspecs
* depending on what object hash the remote uses.
*/
if (!the_repository->hash_algo)
repo_set_hash_algo(the_repository, GIT_HASH_DEFAULT);
Obviously that is kicking the can down the road, but it kind of makes
sense that we would have the same hack in place for remote-curl (which
in practice is only going to be called out-of-repo by ls-remote anyway).
It is only the fact that it happens in a separate process that the
existing fix from 9e89dcb66a is not helping us.
> Additionally, while looking into the remote-curl execution path,
> take the opportunity to remove an unused `#include "git-curl-compat.h"`
> from `remote-curl.c`.
I doubt this is correct.
remote-curl checks GIT_CURL_NEED_TRANSFER_ENCODING_HEADER, which is
defined in git-curl-compat.h. It may work fine without that header if
you have a recent version of curl, but older systems would be subtly
broken.
> +test_expect_success 'ls-remote outside repo does not segfault with fetch refspec' '
> + GIT_CEILING_DIRECTORIES=$(pwd) &&
> + export GIT_CEILING_DIRECTORIES &&
> + mkdir nongit &&
> + (
> + cd nongit &&
> + env GIT_CONFIG_NOSYSTEM=1 \
> + GIT_CONFIG_GLOBAL=/dev/null \
> + GIT_CONFIG_COUNT=1 \
> + GIT_CONFIG_KEY_0=remote.origin.fetch \
> + GIT_CONFIG_VALUE_0="+refs/tags/*:refs/tags/*" \
> + git ls-remote "$HTTPD_URL/smart/repo.git"
> + )
> +'
Some of this is irrelevant to reproducing the bug (like redirecting
system and global config). And it is much easier to use "git -c" to set
temporary config.
We also have a "nongit" helper function already. So I think just:
nongit git \
-c remote.origin.fetch=anything \
ls-remote "$HTTPD_URL/smart/repo.git"
is enough to trigger it. Possibly it is slightly more realistic to
actually use the remote whose refspecs we are configuring:
nongit git \
-c remote.origin.url="$HTTPD_URL/smart/repo.git" \
-c remote.origin.fetch=anything \
ls-remote origin
but as the bug exists now, either is sufficient to trigger it. You could
also add a negative refspec if you want to test that half of the change.
-Peff
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH v3 1/2] refspec: safely parse refspecs outside a repository
2026-03-22 2:35 ` [PATCH v2] refspec: safely parse refspecs outside a repository K Jayatheerth
2026-03-22 3:31 ` Junio C Hamano
2026-03-22 3:53 ` Jeff King
@ 2026-03-22 5:36 ` K Jayatheerth
2026-03-22 5:36 ` [PATCH v3 2/2] refspec: fix typo in comment K Jayatheerth
2026-03-23 22:27 ` [PATCH v3 1/2] refspec: safely parse refspecs outside a repository Junio C Hamano
2026-03-24 1:57 ` [PATCH v4 1/2] remote-curl: fall back to default hash outside repo K Jayatheerth
3 siblings, 2 replies; 17+ messages in thread
From: K Jayatheerth @ 2026-03-22 5:36 UTC (permalink / raw)
To: jayatheerthkulkarni2005; +Cc: git, gitster, joliss42, joliss, peff
When git-remote-http is invoked outside of a repository (for example,
by running `git ls-remote` in a non-git directory with a globally
configured fetch refspec), `the_hash_algo` is left as NULL by
setup_git_directory_gently().
parse_refspec() checks whether the LHS of a refspec is an exact OID by
evaluating `llen == the_hash_algo->hexsz`. With `the_hash_algo` being
NULL, this results in a segmentation fault. The same NULL dereference
exists in the negative refspec path.
Note that builtin/ls-remote already works around a related issue by
setting a fallback hash algorithm before calling into the transport
layer (see 9e89dcb66a). However, since remote-curl runs as a separate
process, that fix does not help here.
Guard both dereferences with a NULL check on `the_hash_algo`. When
operating outside a repository, fetching and pushing are impossible
anyway, so skipping the exact OID check is safe: the exact_sha1 flag
only influences ref prefixes sent to a remote v2 upload-pack during
fetch, and we will never reach that point without a local repository.
Reported-by: Jo Liss <joliss@gmail.com>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
---
refspec.c | 4 ++--
t/t5551-http-fetch-smart.sh | 7 +++++++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/refspec.c b/refspec.c
index 0775358d96..a864a0bac2 100644
--- a/refspec.c
+++ b/refspec.c
@@ -84,7 +84,7 @@ static int parse_refspec(struct refspec_item *item, const char *refspec, int fet
*/
if (!*item->src)
return 0; /* negative refspecs must not be empty */
- else if (llen == the_hash_algo->hexsz && !get_oid_hex(item->src, &unused))
+ else if (the_hash_algo && llen == the_hash_algo->hexsz && !get_oid_hex(item->src, &unused))
return 0; /* negative refpsecs cannot be exact sha1 */
else if (!check_refname_format(item->src, flags))
; /* valid looking ref is ok */
@@ -101,7 +101,7 @@ static int parse_refspec(struct refspec_item *item, const char *refspec, int fet
/* LHS */
if (!*item->src)
; /* empty is ok; it means "HEAD" */
- else if (llen == the_hash_algo->hexsz && !get_oid_hex(item->src, &unused))
+ else if (the_hash_algo && llen == the_hash_algo->hexsz && !get_oid_hex(item->src, &unused))
item->exact_sha1 = 1; /* ok */
else if (!check_refname_format(item->src, flags))
; /* valid looking ref is ok */
diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh
index 73cf531580..a26b6c2844 100755
--- a/t/t5551-http-fetch-smart.sh
+++ b/t/t5551-http-fetch-smart.sh
@@ -782,4 +782,11 @@ test_expect_success 'tag following always works over v0 http' '
test_cmp expect actual
'
+test_expect_success 'ls-remote outside repo does not segfault with fetch refspec' '
+ nongit git \
+ -c remote.origin.url="$HTTPD_URL/smart/repo.git" \
+ -c remote.origin.fetch=anything \
+ ls-remote origin
+'
+
test_done
--
2.53.0
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH v3 2/2] refspec: fix typo in comment
2026-03-22 5:36 ` [PATCH v3 1/2] " K Jayatheerth
@ 2026-03-22 5:36 ` K Jayatheerth
2026-03-23 22:27 ` [PATCH v3 1/2] refspec: safely parse refspecs outside a repository Junio C Hamano
1 sibling, 0 replies; 17+ messages in thread
From: K Jayatheerth @ 2026-03-22 5:36 UTC (permalink / raw)
To: jayatheerthkulkarni2005; +Cc: git, gitster, joliss42, joliss, peff
Fix a long-standing typo in a comment: "refpsecs" -> "refspecs".
Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
---
refspec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refspec.c b/refspec.c
index a864a0bac2..a0c9edfbea 100644
--- a/refspec.c
+++ b/refspec.c
@@ -85,7 +85,7 @@ static int parse_refspec(struct refspec_item *item, const char *refspec, int fet
if (!*item->src)
return 0; /* negative refspecs must not be empty */
else if (the_hash_algo && llen == the_hash_algo->hexsz && !get_oid_hex(item->src, &unused))
- return 0; /* negative refpsecs cannot be exact sha1 */
+ return 0; /* negative refspecs cannot be exact sha1 */
else if (!check_refname_format(item->src, flags))
; /* valid looking ref is ok */
else
--
2.53.0
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH v3 1/2] refspec: safely parse refspecs outside a repository
2026-03-22 5:36 ` [PATCH v3 1/2] " K Jayatheerth
2026-03-22 5:36 ` [PATCH v3 2/2] refspec: fix typo in comment K Jayatheerth
@ 2026-03-23 22:27 ` Junio C Hamano
2026-03-23 23:10 ` Jeff King
1 sibling, 1 reply; 17+ messages in thread
From: Junio C Hamano @ 2026-03-23 22:27 UTC (permalink / raw)
To: K Jayatheerth; +Cc: git, joliss42, joliss, peff
K Jayatheerth <jayatheerthkulkarni2005@gmail.com> writes:
> When git-remote-http is invoked outside of a repository (for example,
> by running `git ls-remote` in a non-git directory with a globally
> configured fetch refspec), `the_hash_algo` is left as NULL by
> setup_git_directory_gently().
>
> parse_refspec() checks whether the LHS of a refspec is an exact OID by
> evaluating `llen == the_hash_algo->hexsz`. With `the_hash_algo` being
> NULL, this results in a segmentation fault. The same NULL dereference
> exists in the negative refspec path.
>
> Note that builtin/ls-remote already works around a related issue by
> setting a fallback hash algorithm before calling into the transport
> layer (see 9e89dcb66a). However, since remote-curl runs as a separate
> process, that fix does not help here.
>
> Guard both dereferences with a NULL check on `the_hash_algo`. When
> operating outside a repository, fetching and pushing are impossible
> anyway, so skipping the exact OID check is safe: the exact_sha1 flag
> only influences ref prefixes sent to a remote v2 upload-pack during
> fetch, and we will never reach that point without a local repository.
>
> Reported-by: Jo Liss <joliss@gmail.com>
> Helped-by: Jeff King <peff@peff.net>
> Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
> ---
> refspec.c | 4 ++--
> t/t5551-http-fetch-smart.sh | 7 +++++++
> 2 files changed, 9 insertions(+), 2 deletions(-)
Looking good. Shall we declare victory and mark the topic for
'next' by now?
Thanks.
> diff --git a/refspec.c b/refspec.c
> index 0775358d96..a864a0bac2 100644
> --- a/refspec.c
> +++ b/refspec.c
> @@ -84,7 +84,7 @@ static int parse_refspec(struct refspec_item *item, const char *refspec, int fet
> */
> if (!*item->src)
> return 0; /* negative refspecs must not be empty */
> - else if (llen == the_hash_algo->hexsz && !get_oid_hex(item->src, &unused))
> + else if (the_hash_algo && llen == the_hash_algo->hexsz && !get_oid_hex(item->src, &unused))
> return 0; /* negative refpsecs cannot be exact sha1 */
> else if (!check_refname_format(item->src, flags))
> ; /* valid looking ref is ok */
> @@ -101,7 +101,7 @@ static int parse_refspec(struct refspec_item *item, const char *refspec, int fet
> /* LHS */
> if (!*item->src)
> ; /* empty is ok; it means "HEAD" */
> - else if (llen == the_hash_algo->hexsz && !get_oid_hex(item->src, &unused))
> + else if (the_hash_algo && llen == the_hash_algo->hexsz && !get_oid_hex(item->src, &unused))
> item->exact_sha1 = 1; /* ok */
> else if (!check_refname_format(item->src, flags))
> ; /* valid looking ref is ok */
> diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh
> index 73cf531580..a26b6c2844 100755
> --- a/t/t5551-http-fetch-smart.sh
> +++ b/t/t5551-http-fetch-smart.sh
> @@ -782,4 +782,11 @@ test_expect_success 'tag following always works over v0 http' '
> test_cmp expect actual
> '
>
> +test_expect_success 'ls-remote outside repo does not segfault with fetch refspec' '
> + nongit git \
> + -c remote.origin.url="$HTTPD_URL/smart/repo.git" \
> + -c remote.origin.fetch=anything \
> + ls-remote origin
> +'
> +
> test_done
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v3 1/2] refspec: safely parse refspecs outside a repository
2026-03-23 22:27 ` [PATCH v3 1/2] refspec: safely parse refspecs outside a repository Junio C Hamano
@ 2026-03-23 23:10 ` Jeff King
2026-03-23 23:39 ` Junio C Hamano
0 siblings, 1 reply; 17+ messages in thread
From: Jeff King @ 2026-03-23 23:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: K Jayatheerth, git, joliss42, joliss
On Mon, Mar 23, 2026 at 03:27:29PM -0700, Junio C Hamano wrote:
> Looking good. Shall we declare victory and mark the topic for
> 'next' by now?
I'm not entirely convinced the better solution isn't just:
diff --git a/remote-curl.c b/remote-curl.c
index 92e40bb682..60774af929 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -1552,6 +1552,11 @@ int cmd_main(int argc, const char **argv)
goto cleanup;
}
+ /* yuck, see 9e89dcb66a (builtin/ls-remote: fall back to SHA1 outside
+ * of a repo, 2024-08-02) */
+ if (nongit)
+ repo_set_hash_algo(the_repository, GIT_HASH_DEFAULT);
+
options.verbosity = 1;
options.progress = !!isatty(2);
options.thin = 1;
That would make the http transport consistent with non-http ones (or at
least any that execute in-process within ls-remote).
Or alternatively, if we think that this use of parse_refspec() is the
only remaining spot for which ls-remote needs a fallback, then we could
apply the patch here and then revert 9e89dcb66a.
-Peff
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH v3 1/2] refspec: safely parse refspecs outside a repository
2026-03-23 23:10 ` Jeff King
@ 2026-03-23 23:39 ` Junio C Hamano
0 siblings, 0 replies; 17+ messages in thread
From: Junio C Hamano @ 2026-03-23 23:39 UTC (permalink / raw)
To: Jeff King; +Cc: K Jayatheerth, git, joliss42, joliss
Jeff King <peff@peff.net> writes:
> On Mon, Mar 23, 2026 at 03:27:29PM -0700, Junio C Hamano wrote:
>
>> Looking good. Shall we declare victory and mark the topic for
>> 'next' by now?
>
> I'm not entirely convinced the better solution isn't just:
>
> diff --git a/remote-curl.c b/remote-curl.c
> index 92e40bb682..60774af929 100644
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -1552,6 +1552,11 @@ int cmd_main(int argc, const char **argv)
> goto cleanup;
> }
>
> + /* yuck, see 9e89dcb66a (builtin/ls-remote: fall back to SHA1 outside
> + * of a repo, 2024-08-02) */
> + if (nongit)
> + repo_set_hash_algo(the_repository, GIT_HASH_DEFAULT);
> +
> options.verbosity = 1;
> options.progress = !!isatty(2);
> options.thin = 1;
>
> That would make the http transport consistent with non-http ones (or at
> least any that execute in-process within ls-remote).
Ah, yes, I like this much better.
Thanks.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH v4 1/2] remote-curl: fall back to default hash outside repo
2026-03-22 2:35 ` [PATCH v2] refspec: safely parse refspecs outside a repository K Jayatheerth
` (2 preceding siblings ...)
2026-03-22 5:36 ` [PATCH v3 1/2] " K Jayatheerth
@ 2026-03-24 1:57 ` K Jayatheerth
2026-03-24 1:57 ` [PATCH v4 2/2] refspec: fix typo in comment K Jayatheerth
2026-03-24 4:25 ` [PATCH v4 1/2] remote-curl: fall back to default hash outside repo Junio C Hamano
3 siblings, 2 replies; 17+ messages in thread
From: K Jayatheerth @ 2026-03-24 1:57 UTC (permalink / raw)
To: jayatheerthkulkarni2005; +Cc: git, gitster, joliss42, joliss, peff
When a remote helper like git-remote-http is invoked outside of a
repository (for example, by running git ls-remote in a non-git
directory), setup_git_directory_gently() leaves the_hash_algo
uninitialized as NULL.
If the user has a globally configured fetch refspec, remote-curl
attempts to parse it during initialization. Inside parse_refspec(),
it checks whether the LHS of the refspec is an exact OID by evaluating
llen == the_hash_algo->hexsz. Because the_hash_algo is NULL, this
results in a segmentation fault.
In 9e89dcb66a (builtin/ls-remote: fall back to SHA1 outside of a repo,
2024-08-02), we added a workaround to ls-remote to fall back to the
default hash algorithm to prevent exactly this type of crash when
parsing refspec capabilities. However, because remote-curl runs as a
separate process, it does not inherit that fallback and crashes anyway.
Instead of pushing a NULL-guard workaround down into parse_refspec(),
fix this by mirroring the ls-remote workaround directly in
remote-curl.c. If we are operating outside a repository, initialize
the_hash_algo to GIT_HASH_DEFAULT. This keeps the HTTP transport
consistent with non-HTTP transports that execute in-process, preventing
crashes without altering the generic refspec parsing logic.
Reported-by: Jo Liss <joliss@gmail.com>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
---
Thanks Peff and Junio this has been informative.
I understood a lot of things here.
remote-curl.c | 5 +++++
t/t5551-http-fetch-smart.sh | 7 +++++++
2 files changed, 12 insertions(+)
diff --git a/remote-curl.c b/remote-curl.c
index 92e40bb682..60774af929 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -1552,6 +1552,11 @@ int cmd_main(int argc, const char **argv)
goto cleanup;
}
+ /* yuck, see 9e89dcb66a (builtin/ls-remote: fall back to SHA1 outside
+ * of a repo, 2024-08-02) */
+ if (nongit)
+ repo_set_hash_algo(the_repository, GIT_HASH_DEFAULT);
+
options.verbosity = 1;
options.progress = !!isatty(2);
options.thin = 1;
diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh
index 73cf531580..a26b6c2844 100755
--- a/t/t5551-http-fetch-smart.sh
+++ b/t/t5551-http-fetch-smart.sh
@@ -782,4 +782,11 @@ test_expect_success 'tag following always works over v0 http' '
test_cmp expect actual
'
+test_expect_success 'ls-remote outside repo does not segfault with fetch refspec' '
+ nongit git \
+ -c remote.origin.url="$HTTPD_URL/smart/repo.git" \
+ -c remote.origin.fetch=anything \
+ ls-remote origin
+'
+
test_done
--
2.53.0
^ permalink raw reply related [flat|nested] 17+ messages in thread* [PATCH v4 2/2] refspec: fix typo in comment
2026-03-24 1:57 ` [PATCH v4 1/2] remote-curl: fall back to default hash outside repo K Jayatheerth
@ 2026-03-24 1:57 ` K Jayatheerth
2026-03-24 4:25 ` [PATCH v4 1/2] remote-curl: fall back to default hash outside repo Junio C Hamano
1 sibling, 0 replies; 17+ messages in thread
From: K Jayatheerth @ 2026-03-24 1:57 UTC (permalink / raw)
To: jayatheerthkulkarni2005; +Cc: git, gitster, joliss42, joliss, peff
Fix a long-standing typo in a comment: "refpsecs" -> "refspecs".
Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
---
refspec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refspec.c b/refspec.c
index 0775358d96..fb89bce1db 100644
--- a/refspec.c
+++ b/refspec.c
@@ -85,7 +85,7 @@ static int parse_refspec(struct refspec_item *item, const char *refspec, int fet
if (!*item->src)
return 0; /* negative refspecs must not be empty */
else if (llen == the_hash_algo->hexsz && !get_oid_hex(item->src, &unused))
- return 0; /* negative refpsecs cannot be exact sha1 */
+ return 0; /* negative refspecs cannot be exact sha1 */
else if (!check_refname_format(item->src, flags))
; /* valid looking ref is ok */
else
--
2.53.0
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH v4 1/2] remote-curl: fall back to default hash outside repo
2026-03-24 1:57 ` [PATCH v4 1/2] remote-curl: fall back to default hash outside repo K Jayatheerth
2026-03-24 1:57 ` [PATCH v4 2/2] refspec: fix typo in comment K Jayatheerth
@ 2026-03-24 4:25 ` Junio C Hamano
1 sibling, 0 replies; 17+ messages in thread
From: Junio C Hamano @ 2026-03-24 4:25 UTC (permalink / raw)
To: K Jayatheerth; +Cc: git, joliss42, joliss, peff
K Jayatheerth <jayatheerthkulkarni2005@gmail.com> writes:
> Instead of pushing a NULL-guard workaround down into parse_refspec(),
> fix this by mirroring the ls-remote workaround directly in
> remote-curl.c. If we are operating outside a repository, initialize
> the_hash_algo to GIT_HASH_DEFAULT. This keeps the HTTP transport
> consistent with non-HTTP transports that execute in-process, preventing
> crashes without altering the generic refspec parsing logic.
Thanks.
>
> Reported-by: Jo Liss <joliss@gmail.com>
> Helped-by: Jeff King <peff@peff.net>
> Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
> ---
> Thanks Peff and Junio this has been informative.
> I understood a lot of things here.
>
> remote-curl.c | 5 +++++
> t/t5551-http-fetch-smart.sh | 7 +++++++
> 2 files changed, 12 insertions(+)
>
> diff --git a/remote-curl.c b/remote-curl.c
> index 92e40bb682..60774af929 100644
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -1552,6 +1552,11 @@ int cmd_main(int argc, const char **argv)
> goto cleanup;
> }
>
> + /* yuck, see 9e89dcb66a (builtin/ls-remote: fall back to SHA1 outside
> + * of a repo, 2024-08-02) */
> + if (nongit)
> + repo_set_hash_algo(the_repository, GIT_HASH_DEFAULT);
> +
> options.verbosity = 1;
> options.progress = !!isatty(2);
> options.thin = 1;
> diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh
> index 73cf531580..a26b6c2844 100755
> --- a/t/t5551-http-fetch-smart.sh
> +++ b/t/t5551-http-fetch-smart.sh
> @@ -782,4 +782,11 @@ test_expect_success 'tag following always works over v0 http' '
> test_cmp expect actual
> '
>
> +test_expect_success 'ls-remote outside repo does not segfault with fetch refspec' '
> + nongit git \
> + -c remote.origin.url="$HTTPD_URL/smart/repo.git" \
> + -c remote.origin.fetch=anything \
> + ls-remote origin
> +'
> +
> test_done
^ permalink raw reply [flat|nested] 17+ messages in thread