Skip to content

[pull] master from git:master#187

Merged
pull[bot] merged 30 commits intoturkdevops:masterfrom
git:master
Apr 1, 2026
Merged

[pull] master from git:master#187
pull[bot] merged 30 commits intoturkdevops:masterfrom
git:master

Conversation

@pull
Copy link
Copy Markdown

@pull pull bot commented Apr 1, 2026

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

vaidas-shopify and others added 30 commits March 17, 2026 09:14
reencode_string_len() allocates len+1 bytes (including the NUL) and
returns the string length in len. strbuf_reencode() was calling
strbuf_attach(sb, out, len, len), so alloc was one byte too small.

strbuf_attach() then calls strbuf_grow(sb, 0). With alloc < len+1,
ALLOC_GROW always reallocates, so we reallocated immediately after
attach even when the strbuf was not extended further. Pass len+1 as
the alloc argument so the existing buffer is reused and the
reallocation is avoided.

Signed-off-by: Vaidas Pilkauskas <vaidas.pilkauskas@shopify.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
strbuf_attach(sb, buf, len, alloc) requires alloc > len (the buffer
must have at least len+1 bytes to hold the NUL). Several call sites
passed alloc == len, relying on strbuf_grow(sb, 0) inside strbuf_attach
to reallocate. Fix these in mailinfo, am, refs/files-backend,
fast-import, and trailer by passing len+1 when the buffer is a
NUL-terminated string (or from strbuf_detach).

Signed-off-by: Vaidas Pilkauskas <vaidas.pilkauskas@shopify.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add retry logic for HTTP 429 (Too Many Requests) responses to handle
server-side rate limiting gracefully. When Git's HTTP client receives
a 429 response, it can now automatically retry the request after an
appropriate delay, respecting the server's rate limits.

The implementation supports the RFC-compliant Retry-After header in
both delay-seconds (integer) and HTTP-date (RFC 2822) formats. If a
past date is provided, Git retries immediately without waiting.

Retry behavior is controlled by three new configuration options
(http.maxRetries, http.retryAfter, and http.maxRetryTime) which are
documented in git-config(1).

The retry logic implements a fail-fast approach: if any delay
(whether from server header or configuration) exceeds maxRetryTime,
Git fails immediately with a clear error message rather than capping
the delay. This provides better visibility into rate limiting issues.

The implementation includes extensive test coverage for basic retry
behavior, Retry-After header formats (integer and HTTP-date),
configuration combinations, maxRetryTime limits, invalid header
handling, environment variable overrides, and edge cases.

Signed-off-by: Vaidas Pilkauskas <vaidas.pilkauskas@shopify.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use test_path_is_file instead of test -f when checking that the
loose object was written to the expected path.

This uses Git's path-checking helper, which provides more specific
failure output than a raw test -f check.

Signed-off-by: Bilal El Khatabi <elkhatabibilal@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
…ht-more

* jk/diff-highlight-identical-pairs:
  contrib/diff-highlight: do not highlight identical pairs
Once upon a time, this was just a script in a directory that could be
run directly. That changed in 0c977db (diff-highlight: split code
into module, 2017-06-15). Let's update the README to make it more clear
that you need to run make.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The diff-highlight code does not rely on any perl features beyond what
perl 5.8 provides. We bumped it to v5.26 along with the rest of the
project's perl scripts in 702d8c1 (Require Perl 5.26.0, 2024-10-23).

There's some value in just having a uniform baseline for the project,
but I think diff-highlight is special here:

  - it's in a contrib/ directory that is not frequently touched, so
    there is little risk of Git developers getting annoyed that modern
    perl features are not available

  - it provides a module used by other projects. In particular,
    diff-so-fancy relies on DiffHighlight.pm but does not otherwise
    require a perl version more modern than 5.8.

Let's drop back to the more conservative requirement.

Signed-off-by: Scott Baker <scott@perturb.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When testing diff-highlight, we pipe the output through a sanitizing
function. This loses the exit status of diff-highlight itself, which
could mean we are missing cases where it crashes or exits unexpectedly.
Use an extra tempfile to avoid the pipe.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most of the ANSI color attributes have an "off" variant. We don't use
these yet in our test suite, so we never bothered to decode them. Add
the ones that match the attributes we encode so we can make use of them.

There are even more attributes not covered on the positive side, so this
is meant to be useful but not all-inclusive.

Note that "nobold" and "nodim" are the same code, so I've decoded this
as "normal intensity".

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The diff-highlight tests use raw color bytes when comparing expected and
actual output. Let's use test_decode_color, which is our usual technique
in other tests. It makes reading test output diffs a bit easier, since
you're not relying on your terminal to interpret the result (or worse,
interpreting characters yourself via "cat -A").

This will also make it easier to add tests with new colors/attributes,
without having to pre-define the byte sequences ourselves.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We added configurable colors long ago in bca45fb (diff-highlight:
allow configurable colors, 2014-11-20), but never actually tested it.
Since we'll be touching the color code in a moment, this is a good time
to beef up the tests.

Note that we cover both the highlight/reset style used by the default
colors, as well as the normal/highlight style added by that commit
(which was previously totally untested).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Users of the module may want to pass in their own color config for a few
obvious reasons:

  - they are pulling the config from different variables than
    diff-highlight itself uses

  - they are loading the config in a more efficient way (say, by parsing
    git-config --list) and don't want to incur the six (!) git-config
    calls that DiffHighlight.pm runs to check all config

Let's allow users of the module to pass in the color config, and
lazy-load it when needed if they haven't.

Signed-off-by: Scott Baker <scott@perturb.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When diff-highlight was written, there was no way to fetch multiple
config keys _and_ have them interpreted as colors. So we were stuck
with either invoking git-config once for each config key, or fetching
them all and converting human-readable color names into ANSI codes
ourselves.

I chose the former, but it means that diff-highlight kicks off 6
git-config processes (even if you haven't configured anything, it has to
check each one).

But since Git 2.18.0, we can do:

   git config --type=color --get-regexp=^color\.diff-highlight\.

to get all of them in one shot.

Note that any callers which pass in colors directly to the module via
@OLD_HIGHLIGHT and @NEW_HIGHLIGHT (like diff-so-fancy plans to do) are
unaffected; those colors suppress any config lookup we'd do ourselves.

You can see the effect like:

  # diff-highlight suppresses git-config's stderr, so dump
  # trace through descriptor 3
  git show d1f33c7 | GIT_TRACE=3 diff-highlight 3>&2 >/dev/null

which drops from 6 lines down to 1.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 9e89dcb (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>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix a long-standing typo in a comment: "refpsecs" -> "refspecs".

Signed-off-by: K Jayatheerth <jayatheerthkulkarni2005@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The topic moves the coccinelle rules from contrib/ to tools/
directory, breaking merges with this topic.

* ps/build-tweaks:
  meson: precompile "git-compat-util.h"
  meson: compile compatibility sources separately
  git-compat-util.h: move warning infra to prepare for PCHs
  builds: move build scripts into "tools/"
  contrib: move "update-unicode.sh" script into "tools/"
  contrib: move "coverage-diff.sh" script into "tools/"
  contrib: move "coccinelle/" directory into "tools/"
  Introduce new "tools/" directory
Add and apply a semantic patch that simplifies the code by letting
strvec_pushv() append the items of a second strvec instead of pushing
them one by one.

Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test added by 71f4960 (t0061: fix test for argv[0] with spaces
(MINGW only), 2019-10-01) checks that we can use a .bat file with spaces
as GIT_SSH.

This is a good test in the sense that it's how the original bug was
detected. And as the commit message there describes, there are some
elements of the bug that are likely to come up with GIT_SSH and not
elsewhere: namely that in addition to the .bat file having spaces, we
must pass an argument with spaces (which happens naturally with ssh,
since we pass the upload-pack shell command for the other side to run).

But using GIT_SSH does complicate matters:

  1. We actually run the ssh command _twice_, once to probe the ssh
     variant with "-G" in fill_ssh_args(), and then a second time to
     actually make the connection. So we have to account for that when
     checking the output.

  2. Our fake ssh .bat file does not actually run ssh. So we expect the
     command to fail, but not before the .bat file has touched the "out"
     marker file that tells us it has run.

     This works now, but is fragile. In particular, the .bat file by
     default will echo commands it runs to stdout. From the perspective
     of the parent Git process, this is protocol-breaking garbage, and
     upon seeing it will die().

     That is OK for now because we don't bother to do any cleanup of the
     child process. But there is a patch under discussion, dd3693e
     (transport-helper, connect: use clean_on_exit to reap children on
     abnormal exit, 2026-03-12), which causes us to kill() the .bat
     process. This happens before it actually touches the "out" file,
     causing the test to fail.

We can simplify this by just using the "test-tool run-command" helper.
That lets us run whatever command we like with the arguments we want.
The argument here has a space, which is enough to trigger the original
bug that 71f4960 was testing. I verified that by reverting eb7c786
(mingw: support spawning programs containing spaces in their names,
2019-07-16), the original fix, and confirming that the test fails (but
succeeds without the revert).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Factor the "git repo info" and "git repo structure" usage
strings into shared macros so they can be reused in multiple
usage arrays.

This is a preparatory refactoring for subsequent changes to
subcommand-specific help output.

Signed-off-by: Mahi Kassa <mahlet.takassa@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use subcommand-specific usage arrays for "git repo info" and
"git repo structure" so that each command shows only its own
synopsis in help output.

Add tests to cover the subcommand help behavior.

Signed-off-by: Mahi Kassa <mahlet.takassa@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recently some GitHub CI jobs were broken by update on the platform
side, which was eventually resolved by image rollback, but in the
meantime Dscho invented a workaround patch to sidestep the broken
part of the platform.  Their future image update may contain the
same bug, in which case the workaround may again become needed.

As we do not want to be building with workaround that avoids system
regexp library altogether unless the system is known to be broken,
so short of an automated "detect broken system and apply workaround"
mechanism, let's use the folks who are compiling the code to detect
breakage on their system and cope with the breakage ;-)

Signed-off-by: Junio C Hamano <gitster@pobox.com>
The HTTP transport learned to react to "429 Too Many Requests".

* vp/http-rate-limit-retries:
  http: add support for HTTP 429 rate limit retries
  strbuf_attach: fix call sites to pass correct alloc
  strbuf: pass correct alloc to strbuf_attach() in strbuf_reencode()
Various updates to contrib/diff-highlight, including documentation
updates, test improvements, and color configuration handling.

* jk/diff-highlight-more:
  diff-highlight: fetch all config with one process
  diff-highlight: allow module callers to pass in color config
  diff-highlight: test color config
  diff-highlight: use test_decode_color in tests
  t: add matching negative attributes to test_decode_color
  diff-highlight: check diff-highlight exit status in tests
  diff-highlight: drop perl version dependency back to 5.8
  diff-highlight: mention build instructions
Test clean-up.

* bk/t5315-test-path-is-helpers:
  t5315: use test_path_is_file for loose-object check
Code paths that loop over another array to push each element into a
strvec have been rewritten to use strvec_pushv() instead.

* rs/use-strvec-pushv:
  use strvec_pushv() to add another strvec
In case homebrew breaks REG_ENHANCED again, leave a in-code comment
to suggest use of our replacement regex as a workaround.

* jc/macos-homebrew-wo-reg-enhanced:
  regexp: leave a pointer to resurrect workaround for Homebrew
"git repo info -h" and "git repo structure -h" limit their help output
to the part that is specific to the subcommand.

* mk/repo-help-strings:
  repo: show subcommand-specific help text
  repo: factor repo usage strings into shared macros
A test to run a .bat file with whitespaces in the name with arguments
with whitespaces in them was flaky in that sometimes it got killed
before it produced expected side effects, which has been rewritten to
make it more robust.

* jk/t0061-bat-test-update:
  t0061: simplify .bat test
"git ls-remote '+refs/tags/*:refs/tags/*' https://..." run outside a
repository would dereference a NULL while trying to see if the given
refspec is a single-object refspec, which has been corrected.

* kj/refspec-parsing-outside-repository:
  refspec: fix typo in comment
  remote-curl: fall back to default hash outside repo
Signed-off-by: Junio C Hamano <gitster@pobox.com>
@pull pull bot locked and limited conversation to collaborators Apr 1, 2026
@pull pull bot added the ⤵️ pull label Apr 1, 2026
@pull pull bot merged commit cf2139f into turkdevops:master Apr 1, 2026
1 of 2 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants