From f6c8bae5cdba1836d76e7eed3b41547d49869f06 Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Sat, 27 Jun 2026 17:17:56 +0000 Subject: [PATCH 1/4] http: accept https:// proxies again Since 663d7abe07ea (http: reject unsupported proxy URL schemes, 2026-05-05), set_curl_proxy_type() returns 0 only for the "http" and SOCKS variants via dedicated early returns, and -1 for everything else. The "https" branch configures the CURL handle for HTTPS proxying but then falls through to the trailing `return -1` intended for unknown schemes, so the caller in get_curl_handle() treats a perfectly valid https:// proxy URL as unsupported and refuses to use it. Noticed while looking into a Coverity report against the same function; the unchecked curl_easy_setopt() return values it flags are orthogonal to this fix. Assisted-by: Opus 4.7 Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano --- http.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/http.c b/http.c index 8e5a4d8bcf8eac..8c0f83136589ff 100644 --- a/http.c +++ b/http.c @@ -802,6 +802,8 @@ static int set_curl_proxy_type(CURL *result, const char *protocol) if (has_proxy_cert_password()) curl_easy_setopt(result, CURLOPT_PROXY_KEYPASSWD, proxy_cert_auth.password); + + return 0; } return -1; From dc51aedd5302677f80bb09e7df627e441111dd3f Mon Sep 17 00:00:00 2001 From: Jeff King Date: Sun, 28 Jun 2026 04:00:09 -0400 Subject: [PATCH 2/4] t/lib-httpd: bump apache timeout Since enabling more tests with 7a094d68a2 (ci: run expensive tests on push builds to integration branches, 2026-05-08), we sometimes see test failures or timeouts in GitHub CI. The culprit seems to be the "enormous ref negotiation" test in t5551, which creates ~100k tag refs in our http server-side repo. Iterating through the loose refs of this repo to generate a ref advertisement can take a long time, especially on a platform with slow I/O. On my otherwise unloaded local machine, a cold cache ref advertisement takes ~10s. On a busy CI machine running tests in parallel, it can presumably top 60s, which runs afoul of Apache's default CGI timeout. The result in t5551 is a test failure, where Apache simply hangs up the connection and the client reports an error. But worse, t5559 runs the same test with HTTP/2, and a bug in Apache causes the connection to hang indefinitely! We eventually see this as a CI timeout after 6 hours. Let's bump Apache's timeout to something much larger: 600 seconds. This doesn't eliminate the possibility of a timeout, but it makes it much less likely. It should eliminate both the test failures and the CI timeouts in practice, and it protects us from running into similar problems with other tests in the future. There are two counter-arguments to consider. One, could/should we just make the test faster? Probably yes. The biggest mistake here is having such an absurd number of unpacked refs on a system which is bottle-necked on I/O. But I think it's worth bumping the timeout so that we can fix this (and possibly other) correctness issues, and then consider performance separately (which we'll do in subsequent patches). And two, is this just papering over a problem that users might see in the real world? We could teach Git to handle this case more gracefully with optimizations or keep-alives. But I think it's really an artificial situation. You need a combination of this silly number of loose refs, plus a very heavily loaded system. If you were trying to run a real server and it took more than 60s to generate the ref advertisement, I don't think the timeout is your biggest problem. Your crappy service is, and you should adjust your resources to match your load. I.e., it is probably reasonable for Git to assume that advertisements happen fast-ish and don't need protocol-level keepalives. Though the patch here is small, tons of work went into analyzing the problem. Many thanks to the contributors credited below. Helped-by: Michael Montalbo Helped-by: Patrick Steinhardt Signed-off-by: Jeff King Signed-off-by: Junio C Hamano --- t/lib-httpd/apache.conf | 1 + 1 file changed, 1 insertion(+) diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf index 40a690b0bb7c9b..4149fc1078a877 100644 --- a/t/lib-httpd/apache.conf +++ b/t/lib-httpd/apache.conf @@ -4,6 +4,7 @@ DocumentRoot www LogFormat "%h %l %u %t \"%r\" %>s %b" common CustomLog access.log common ErrorLog error.log +Timeout 600 LoadModule log_config_module modules/mod_log_config.so From f6ef747a7c7a80be7f53a832d0a7d28617071c3d Mon Sep 17 00:00:00 2001 From: Jeff King Date: Sun, 28 Jun 2026 04:03:45 -0400 Subject: [PATCH 3/4] t5551: put many-tags case into its own repo Most of the t5551 http fetch tests use a handful of refs. But there are a few test cases which check our handling of large numbers of refs. These tests use the same server-side repo, so all subsequent tests end up having to consider those extra refs, too. The result is that the test script is a bit slower than it needs to be. In a normal run, moving the "2,000 tags" test into its own repo drops my runtime for the whole script from ~2.7s to ~1.9s. This is a modest gain, but when we add the "--long" flag it gets much bigger. There we trigger a test (marked with EXPENSIVE) that adds 100,000 tags, and the script runtime jumps to ~95s. But if we use the same "many tags" repo for that, our runtime drops to just ~37s. This is a pretty easy win to drop the cost of the script. It may even be a larger gain on a heavily loaded system, since one of the main costs here is unpacked refs, which are heavy on system time and I/O costs. It's possible we are reducing test coverage, since all of those other tests were inadvertently using large ref advertisements (and thus could have uncovered some unexpected interaction). But that seems somewhat unlikely; the tests targeted at the large number of refs are doing roughly similar things to the other tests. Note that the real performance culprit is the 100k-tag --long test, not the 2k-tag one. So we could just let the 100k one use its own repo, and keep the 2k tags in the main repo. But since these two tests are somewhat interlinked, it's easier to just move them both (and it does provide a small gain even for the 2000-tag test). I also notice that the 2000-tag test is gated on the CMDLINE_LIMIT prereq, and without that the later EXPENSIVE test will fail (since we won't have a too-many-refs clone). Nobody seems to have noticed or complained after many years, and I left it alone for this patch. Signed-off-by: Jeff King [jc: made the new "many-tags.git" bare to match the original "repo.git"] Signed-off-by: Junio C Hamano --- t/t5551-http-fetch-smart.sh | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh index e236e526f0defb..dcff0bc7d46421 100755 --- a/t/t5551-http-fetch-smart.sh +++ b/t/t5551-http-fetch-smart.sh @@ -397,15 +397,16 @@ create_tags () { } test_expect_success 'create 2,000 tags in the repo' ' + git init --bare "$HTTPD_DOCUMENT_ROOT_PATH/many-tags.git" && ( - cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" && + cd "$HTTPD_DOCUMENT_ROOT_PATH/many-tags.git" && create_tags 1 2000 ) ' test_expect_success CMDLINE_LIMIT \ 'clone the 2,000 tag repo to check OS command line overflow' ' - run_with_limited_cmdline git clone $HTTPD_URL/smart/repo.git too-many-refs && + run_with_limited_cmdline git clone $HTTPD_URL/smart/many-tags.git too-many-refs && ( cd too-many-refs && git for-each-ref refs/tags >actual && @@ -483,12 +484,12 @@ test_expect_success 'test allowanysha1inwant with unreachable' ' test_expect_success EXPENSIVE 'http can handle enormous ref negotiation' ' test_when_finished "rm -f tags" && ( - cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" && + cd "$HTTPD_DOCUMENT_ROOT_PATH/many-tags.git" && create_tags 2001 50000 ) && git -C too-many-refs fetch -q --tags && ( - cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" && + cd "$HTTPD_DOCUMENT_ROOT_PATH/many-tags.git" && create_tags 50001 100000 ) && git -C too-many-refs fetch -q --tags && From e9019fcafe0040228b8631c30f97ae1adb61bcdc Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Mon, 29 Jun 2026 07:58:39 -0700 Subject: [PATCH 4/4] Git 2.55 Signed-off-by: Junio C Hamano --- Documentation/RelNotes/2.55.0.adoc | 4 +++- GIT-VERSION-GEN | 2 +- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/RelNotes/2.55.0.adoc b/Documentation/RelNotes/2.55.0.adoc index 8543cad65e491f..f5643534dcc19c 100644 --- a/Documentation/RelNotes/2.55.0.adoc +++ b/Documentation/RelNotes/2.55.0.adoc @@ -31,7 +31,9 @@ UI, Workflows & Features subcommand "git url-parse". * Misspelt proxy URL (e.g., httt://...) did not trigger any warning - or failure, which has been corrected. + or failure, which has been corrected. We had a regression in this + update that broke https:// proxies, but that has been caught and + corrected. * Document the fact that .git/info/exclude is shared across worktrees linked to the same repository. diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN index 04b0a8c70f259a..6e4df991932910 100755 --- a/GIT-VERSION-GEN +++ b/GIT-VERSION-GEN @@ -1,6 +1,6 @@ #!/bin/sh -DEF_VER=v2.55.0-rc2 +DEF_VER=v2.55.0 LF=' '