From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 14 Aug 2024 21:54:49 +0000 (-0700)
Subject: Merge branch 'ps/ls-remote-out-of-repo-fix'
X-Git-Tag: v2.47.0-rc0~148
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=760348212b16379d2646751c2cd18a028cbdd02d;p=thirdparty%2Fgit.git

Merge branch 'ps/ls-remote-out-of-repo-fix'

A recent update broke "git ls-remote" used outside a repository,
which has been corrected.

* ps/ls-remote-out-of-repo-fix:
  builtin/ls-remote: fall back to SHA1 outside of a repo
---

760348212b16379d2646751c2cd18a028cbdd02d
diff --cc builtin/ls-remote.c
index 5b61af5d78,6da63a67f5..0a491595ca
--- a/builtin/ls-remote.c
+++ b/builtin/ls-remote.c
@@@ -90,10 -91,30 +90,25 @@@ int cmd_ls_remote(int argc, const char 
  			     PARSE_OPT_STOP_AT_NON_OPTION);
  	dest = argv[0];
  
+ 	/*
+ 	 * 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_SHA1);
+ 
  	packet_trace_identity("ls-remote");
  
 -	if (argc > 1) {
 -		int i;
 -		CALLOC_ARRAY(pattern, argc);
 -		for (i = 1; i < argc; i++) {
 -			pattern[i - 1] = xstrfmt("*/%s", argv[i]);
 -		}
 -	}
 +	for (int i = 1; i < argc; i++)
 +		strvec_pushf(&pattern, "*/%s", argv[i]);
  
  	if (flags & REF_TAGS)
  		strvec_push(&transport_options.ref_prefixes, "refs/tags/");