Tags: gitgitgadget/git
Tags
t2004: use test_path_is_file instead of test -f From: Lambert Duclos-de Guise <lambertddg@gmail.com> Replace 'test -f' with the helper function 'test_path_is_file' to provide better error messages upon failure. Signed-off-by: Lambert Duclos-de Guise <lambertddg@gmail.com> Submitted-As: https://lore.kernel.org/git/pull.2049.git.1771694893208.gitgitgadget@gmail.com
Avoid the_repository in merge-ort and replay Changes since v2: * In first patch, actually avoid the_repository when attempting to remove check against the_repository * Fix commit message of patch 3 due to the new patch 1. * Slight tweak to commit message of patch 6. Changes since v1: * Add a preparatory patch removing the_repository check from blob prefetching in both merge-ort and diff*; it's no longer necessary * Fix casing mismatch * Simplify the hammer a bit based on the new first patch, but add some simple comments explaining it Remove explicit uses of the_repository and the_hash_algo from merge-ort, and since this has now been done multiple times for both merge-ort and replay, implement a small measure to prevent them from returning to either merge-ort or replay. See https://lore.kernel.org/git/CABPp-BH7E1Bh2g0vR3T4NEsv34DvFQPzMuJSsqtOAaWY-fFCxg@mail.gmail.com/ and https://lore.kernel.org/git/CABPp-BFuwvqiCTCCpoyT6em9_1-qrgPWHWhrufQ3UuZ+Kfkb6A@mail.gmail.com/ for recent discussions on these. As noted in the comments on v1, I actually do not know why prefetch_for_content_merges() needs to use the_repository. When I introduced it back in 2bff554 (merge-ort: add prefetching for content merges, 2021-06-22), I was just looking at diffcore_std() and trying to mimic how it did the prefetch, and it has such a comparison. If anyone knows why diffcore_std() needs to compare against the_repository, I'd love to hear... Series overview: Patches 1-3: Mostly mechanical removal of existing uses Patches 4-5: Simple hammer to prevent the problem from returning Elijah Newren (6): merge,diff: remove the_repository check before prefetching blobs merge-ort: pass repository to write_tree() merge-ort: replace the_repository with opt->repo merge-ort: replace the_hash_algo with opt->repo->hash_algo merge-ort: prevent the_repository from coming back replay: prevent the_repository from coming back diff.c | 2 +- diffcore-break.c | 2 +- diffcore-rename.c | 4 +- merge-ort.c | 94 +++++++++++++++++++++++++---------------------- replay.c | 6 +++ 5 files changed, 61 insertions(+), 47 deletions(-) base-commit: 73fd778 Submitted-As: https://lore.kernel.org/git/pull.2048.v3.git.1771718393.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2048.git.1771406115.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2048.v2.git.1771552788.gitgitgadget@gmail.com
branch: add 'branch.addCurrentBranchAsPrefix' config param From: VALERI Yoann <yoann.valeri@cea.fr> This patch adds a new configuration parameter for the branch creation feature: 'branch.addCurrentBranchAsPrefix'. When set to true, if one creates a new branch with either `git branch`, `git checkout -[bB]` or `git switch -[cC]`, we will now retrieve the current branch's name, and use it as prefix for the name of the newly created branch, alongside a hyphen separating the two. For instance, using this parameter, and attempting to create a branch 'test' while on the 'main' branch will instead create a branch 'main-test'. This parameters is useful for projects handling many branches, with features often needing backport on different branches, so as to reduce the time taken to create branches without having to come up with clever names. Signed-off-by: VALERI Yoann <yoann.valeri@cea.fr> Submitted-As: https://lore.kernel.org/git/pull.2202.git.git.1771574833967.gitgitgadget@gmail.com
Avoid the_repository in merge-ort and replay Changes since v1: * Add a preparatory patch removing the_repository check from blob prefetching in both merge-ort and diff*; it's no longer necessary * Fix casing mismatch * Simplify the hammer a bit based on the new first patch, but add some simple comments explaining it Remove explicit uses of the_repository and the_hash_algo from merge-ort, and since this has now been done multiple times for both merge-ort and replay, implement a small measure to prevent them from returning to either merge-ort or replay. See https://lore.kernel.org/git/CABPp-BH7E1Bh2g0vR3T4NEsv34DvFQPzMuJSsqtOAaWY-fFCxg@mail.gmail.com/ and https://lore.kernel.org/git/CABPp-BFuwvqiCTCCpoyT6em9_1-qrgPWHWhrufQ3UuZ+Kfkb6A@mail.gmail.com/ for recent discussions on these. As noted in the comments on v1, I actually do not know why prefetch_for_content_merges() needs to use the_repository. When I introduced it back in 2bff554 (merge-ort: add prefetching for content merges, 2021-06-22), I was just looking at diffcore_std() and trying to mimic how it did the prefetch, and it has such a comparison. If anyone knows why diffcore_std() needs to compare against the_repository, I'd love to hear... Series overview: Patches 1-3: Mostly mechanical removal of existing uses Patches 4-5: Simple hammer to prevent the problem from returning Elijah Newren (6): merge,diff: remove the_repository check before prefetching blobs merge-ort: pass repository to write_tree() merge-ort: replace the_repository with opt->repo merge-ort: replace the_hash_algo with opt->repo->hash_algo merge-ort: prevent the_repository from coming back replay: prevent the_repository from coming back diff.c | 2 +- diffcore-break.c | 2 +- diffcore-rename.c | 4 +- merge-ort.c | 94 +++++++++++++++++++++++++---------------------- replay.c | 6 +++ 5 files changed, 61 insertions(+), 47 deletions(-) base-commit: 73fd778 Submitted-As: https://lore.kernel.org/git/pull.2048.v2.git.1771552788.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2048.git.1771406115.gitgitgadget@gmail.com
osxkeychain: define build targets in the top-level Makefile. From: Koji Nakamaru <koji.nakamaru@gree.net> The fix for git-credential-osxkeychain in 4580bcd (osxkeychain: avoid incorrectly skipping store operation, 2025-11-14) introduced linkage with libgit.a, and its Makefile was adjusted accordingly. However, the build fails as of 864f55e because several macOS-specific refinements were applied to the top-level Makefile and config.mak.uname, such as: - 363837a (macOS: make Homebrew use configurable, 2025-12-24) - cee341e (macOS: use iconv from Homebrew if needed and present, 2025-12-24) - d281241 (utf8.c: enable workaround for iconv under macOS 14/15, 2026-01-12) Since libgit.a and its corresponding header files depend on many flags defined in the top-level Makefile, these flags must be consistently defined when building git-credential-osxkeychain. Continuing to manually adjust the git-credential-osxkeychain Makefile is cumbersome and fragile. Define the build targets for git-credential-osxkeychain in the top-level Makefile and modify its local Makefile to simply rely on those targets. Helped-by: Junio C Hamano <gitster@pobox.com> Reported-by: D. Ben Knoble <ben.knoble@gmail.com> Helped-by: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com> Signed-off-by: Koji Nakamaru <koji.nakamaru@gree.net> Submitted-As: https://lore.kernel.org/git/pull.2046.v4.git.1771551540816.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2046.git.1770746461307.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2046.v2.git.1770775169908.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2046.v3.git.1771391650713.gitgitgadget@gmail.com
apply: normalize path in --directory argument From: Joaquim Rocha <joaquim@amutable.com> When passing a relative path like --directory=./some/sub, the leading "./" caused apply to prepend it literally to patch filenames, resulting in an error (invalid path). There may be more cases like this where users pass some/./path to the directory which can easily be normalized to an acceptable path, so these changes try to normalize the path before using it. Signed-off-by: Joaquim Rocha <joaquim@amutable.com> Submitted-As: https://lore.kernel.org/git/pull.2198.v2.git.git.1771373732749.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2198.git.git.1771002510709.gitgitgadget@gmail.com
Avoid the_repository in merge-ort and replay Remove explicit uses of the_repository and the_hash_algo from merge-ort, and since this has now been done multiple times for both merge-ort and replay, implement a small measure to prevent them from returning to either merge-ort or replay. See https://lore.kernel.org/git/CABPp-BH7E1Bh2g0vR3T4NEsv34DvFQPzMuJSsqtOAaWY-fFCxg@mail.gmail.com/ and https://lore.kernel.org/git/CABPp-BFuwvqiCTCCpoyT6em9_1-qrgPWHWhrufQ3UuZ+Kfkb6A@mail.gmail.com/ for recent discussions on these. Series overview: Patches 1-3: Mostly mechanical removal of existing uses Patches 4-5: Simple hammer to prevent the problem from returning Elijah Newren (5): merge-ort: pass repository to write_tree() merge-ort: replace the_repository with opt->repo merge-ort: replace the_hash_algo with opt->repo->hash_algo merge-ort: prevent the_repository from coming back replay: prevent the_repository from coming back merge-ort.c | 92 ++++++++++++++++++++++++++++------------------------- replay.c | 2 ++ 2 files changed, 51 insertions(+), 43 deletions(-) base-commit: 73fd778 Submitted-As: https://lore.kernel.org/git/pull.2048.git.1771406115.gitgitgadget@gmail.com
doc: fetch: document `--jobs=0` behavior From: "Daniel D. Beck" <daniel@ddbeck.com> In c39952b (fetch: choose a sensible default with --jobs=0 again, 2023-02-20), the `--jobs=0` behavior was (re)introduced, but it went undocumented. Since this is the same behavior as `git -c fetch.parallel=0 fetch`, which is documented, this change creates symmetry between the two documentation sections. Signed-off-by: Daniel D. Beck <daniel@ddbeck.com> Submitted-As: https://lore.kernel.org/git/pull.2047.git.1771443159369.gitgitgadget@gmail.com
osxkeychain: define build targets in the top-level Makefile. From: Koji Nakamaru <koji.nakamaru@gree.net> The fix for git-credential-osxkeychain in 4580bcd (osxkeychain: avoid incorrectly skipping store operation) introduced linkage with libgit.a, and its Makefile was adjusted accordingly. However, the build fails as of 864f55e because several macOS-specific refinements were applied to the top-level Makefile and config.mak.uname, such as: - 363837a (macOS: make Homebrew use configurable, 2025-12-24) - cee341e (macOS: use iconv from Homebrew if needed and present, 2025-12-24) - d281241 (utf8.c: enable workaround for iconv under macOS 14/15, 2026-01-12) Since libgit.a and its corresponding header files depend on many flags defined in the top-level Makefile, these flags must be consistently defined when building git-credential-osxkeychain. Continuing to manually adjust the git-credential-osxkeychain Makefile is cumbersome and fragile. Define the build targets for git-credential-osxkeychain in the top-level Makefile and modify its local Makefile to simply rely on those targets. Helped-by: Junio C Hamano <gitster@pobox.com> Reported-by: D. Ben Knoble <ben.knoble@gmail.com> Signed-off-by: Koji Nakamaru <koji.nakamaru@gree.net> Submitted-As: https://lore.kernel.org/git/pull.2046.v3.git.1771391650713.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2046.git.1770746461307.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.2046.v2.git.1770775169908.gitgitgadget@gmail.com
http: add support for HTTP 429 rate limit retries
Changes since v3:
* Clean up of all strbuf_attach() call sites
* Add strbuf_attach() contract enforcement via BUG()
Changes since v2:
* New preparatory patch: Introduced show_http_message_fatal() helper
function to reduce code duplication in remote-curl.c (suggested by Taylor
Blau)
* Removed specific HTTP_RATE_LIMITED error handling from http-push.c and
http-walker.c for the obsolete "dumb" protocol, allowing generic error
handling to take over (suggested by Jeff King)
* Added support for CURLINFO_RETRY_AFTER on curl >= 7.66.0, falling back to
manual header parsing on older versions
* Simplified retry/delay architecture: replaced complex non-blocking
"delayed slot" mechanism with simple blocking sleep() call in the retry
loop, removing ~66 lines of timing logic (suggested by Jeff King)
* Fixed Retry-After: 0 handling to allow immediate retry as specified by
RFC 9110
* Changed http.retryAfter default from -1 to 0, so Git will retry
immediately when encountering HTTP 429 without a Retry-After header,
rather than failing with a configuration error
* Improved error messages: shortened to be more concise
* Fixed coding style issues: removed unnecessary curly braces, changed x ==
0 to !x (per CodingGuidelines)
* Improved test portability: replaced non-portable date(1) commands with
test-tool date, added nanosecond-precision timing with getnanos, replaced
cut(1) with POSIX shell parameter expansion
* Split out strbuf.c bugfix into separate preparatory patch (the
strbuf_reencode alloc size fix is unrelated to HTTP 429 support)
* Squashed separate trace2 logging patch into main HTTP 429 retry support
commit
* Kept header_is_last_match assignment for Retry-After to prevent incorrect
handling of HTTP header continuation lines
The implementation includes:
1. A bug fix in strbuf_reencode() that corrects the allocation size passed
to strbuf_attach(), passing len+1 instead of len so that the existing
buffer is reused rather than immediately reallocated.
2. A cleanup of all strbuf_attach() call sites that were passing alloc ==
len, leaving no room for the NUL terminator. Sites with a
known-NUL-terminated buffer now pass len+1; sites where the source
buffer has no trailing NUL (ll_merge output) are converted to use
strbuf_add() instead.
3. A hardening of strbuf_attach() itself: the internal strbuf_grow() that
silently papered over incorrect alloc values is replaced with an
explicit BUG() check, enforcing the documented contract that alloc must
be greater than len.
4. A new show_http_message_fatal() helper in remote-curl.c that combines
the repeated pattern of show_http_message() followed by die() into a
single NORETURN function, reducing boilerplate at existing call sites
and providing a clean hook for the retry logic.
5. The main feature: HTTP 429 retry logic with support for the Retry-After
header (both delay-seconds and HTTP-date formats), configurable via
http.maxRetries, http.retryAfter, and http.maxRetryTime options. If any
computed delay exceeds maxRetryTime the request fails immediately with a
clear diagnostic rather than capping and retrying silently.
Vaidas Pilkauskas (5):
strbuf: pass correct alloc to strbuf_attach() in strbuf_reencode()
strbuf_attach: fix all call sites to pass correct alloc
strbuf: replace strbuf_grow() in strbuf_attach() with BUG() check
remote-curl: introduce show_http_message_fatal() helper
http: add support for HTTP 429 rate limit retries
Documentation/config/http.adoc | 23 +++
apply.c | 3 +-
builtin/am.c | 2 +-
builtin/fast-import.c | 2 +-
git-curl-compat.h | 8 +
http.c | 190 +++++++++++++++++++++--
http.h | 2 +
mailinfo.c | 2 +-
refs/files-backend.c | 2 +-
remote-curl.c | 49 +++---
rerere.c | 3 +-
strbuf.c | 5 +-
t/lib-httpd.sh | 1 +
t/lib-httpd/apache.conf | 8 +
t/lib-httpd/http-429.sh | 98 ++++++++++++
t/meson.build | 1 +
t/t5584-http-429-retry.sh | 266 +++++++++++++++++++++++++++++++++
trailer.c | 2 +-
18 files changed, 629 insertions(+), 38 deletions(-)
create mode 100644 t/lib-httpd/http-429.sh
create mode 100755 t/t5584-http-429-retry.sh
base-commit: 73fd778
Submitted-As: https://lore.kernel.org/git/pull.2008.v4.git.1771423748.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2008.git.1764160227.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2008.v2.git.1766069088.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.2008.v3.git.1771326521.gitgitgadget@gmail.com
PreviousNext