git/strbuf.c, branch jch

Merge branch 'vp/http-rate-limit-retries'

2026-04-01T17:28:18Z

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()

strbuf: pass correct alloc to strbuf_attach() in strbuf_reencode()

2026-03-17T16:14:19Z

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 Signed-off-by: Junio C Hamano

global: constify some pointers that are not written to

2026-02-06T01:52:49Z

The recent glibc 2.43 release had the following change listed in its NEWS file: For ISO C23, the functions bsearch, memchr, strchr, strpbrk, strrchr, strstr, wcschr, wcspbrk, wcsrchr, wcsstr and wmemchr that return pointers into their input arrays now have definitions as macros that return a pointer to a const-qualified type when the input argument is a pointer to a const-qualified type. When compiling with GCC 15, which defaults to -std=gnu23, this causes many warnings like this: merge-ort.c: In function ‘apply_directory_rename_modifications’: merge-ort.c:2734:36: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] 2734 | char *last_slash = strrchr(cur_path, '/'); | ^~~~~~~ This patch fixes the more obvious ones by making them const when we do not write to the returned pointer. Signed-off-by: Collin Funk Signed-off-by: Junio C Hamano

Merge branch 'js/prep-symlink-windows'

2026-01-21T16:29:00Z

Further preparation to upstream symbolic link support on Windows. * js/prep-symlink-windows: trim_last_path_component(): avoid hard-coding the directory separator strbuf_readlink(): support link targets that exceed 2*PATH_MAX strbuf_readlink(): avoid calling `readlink()` twice in corner-cases init: do parse _all_ core.* settings early mingw: do resolve symlinks in `getcwd()`

strbuf_readlink(): support link targets that exceed 2*PATH_MAX

2026-01-10T02:28:36Z

The `strbuf_readlink()` function refuses to read link targets that exceed 2*PATH_MAX (even if a sufficient size was specified by the caller). The reason that that limit is 2*PATH_MAX instead of PATH_MAX is that the symlink targets do not need to be normalized. After running `ln -s a/../a/../a/../a/../b c`, the target of the symlink `c` will not be normalized to `b` but instead be much longer. As such, symlink targets' lengths can far exceed PATH_MAX. They are frequently much longer than 2*PATH_MAX on Windows, which actually supports paths up to 32,767 characters, but sets PATH_MAX to 260 for backwards compatibility. For full details, see https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation Let's just hard-code the limit used by `strbuf_readlink()` to 32,767 and make it independent of the current platform's PATH_MAX. Based-on-a-patch-by: Karsten Blees Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

strbuf_readlink(): avoid calling `readlink()` twice in corner-cases

2026-01-10T02:28:36Z

The `strbuf_readlink()` function calls `readlink()`` twice if the hint argument specifies the exact size of the link target (e.g. by passing stat.st_size as returned by `lstat()`). This is necessary because `readlink(..., hint) == hint` could mean that the buffer was too small. Use `hint + 1` as buffer size to prevent this. Signed-off-by: Karsten Blees Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

builtin/repo: add inflated object info to structure table

2025-12-18T00:02:31Z

Update the table output format for the git-repo(1) structure command to begin printing the total inflated object size info by object type. To be more human-friendly, larger values are scaled down and displayed with the appropriate unit prefix. Output for the keyvalue and nul formats remains unchanged. Signed-off-by: Justin Tobler Signed-off-by: Junio C Hamano

builtin/repo: humanise count values in structure output

2025-12-18T00:02:31Z

The table output format for the git-repo(1) structure subcommand is used by default and intended to provide output to users in a human-friendly manner. When the reference/object count values in a repository are large, it becomes more cumbersome for users to read the values. For larger values, update the table output format to instead produce more human-friendly count values that are scaled down with the appropriate unit prefix. Output for the keyvalue and nul formats remains unchanged. Signed-off-by: Justin Tobler Signed-off-by: Junio C Hamano

strbuf: split out logic to humanise byte values

2025-12-18T00:02:31Z

In a subsequent commit, byte size values displayed in table output for the git-repo(1) "structure" subcommand will be shown in a more human-readable format with the appropriate unit prefixes. For this usecase, the downscaled values and unit strings must be handled separately to ensure proper column alignment. Split out logic from strbuf_humanise() to downscale byte values and determine the corresponding unit prefix into a separate humanise_bytes() function that provides seperate value and unit strings. Note that the "byte" string in "t/helper/test-simple-ipc.c" is unmarked for translation here so that it doesn't conflict with the newly defined plural "byte/bytes" translation and instead uses it. Signed-off-by: Justin Tobler Signed-off-by: Junio C Hamano

strbuf: convert predicates to return bool

2025-07-16T15:18:06Z

Now that the string predicates defined in git-compat-util.h all return bool let's convert the return type of the string predicates in strbuf.{c,h} to match them. Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano