git/tools, branch seen

Merge branch 'rs/strbuf-add-oid-hex' into seen

2026-05-18T05:29:04Z

Formatting object name in full hexadecimal form has been optimized by using a new strbuf_add_oid_hex() helper function. Comments? * rs/strbuf-add-oid-hex: hex: add and use strbuf_add_oid_hex()

generate-configlist: collapse depfile for older Ninja

2026-05-16T13:19:56Z

The tools/generate-configlist.sh script generates two files: * config-list.h * config-list.h.d The former is included by the source code and the latter defines on which files the former depends. The contents of `config-list.h.d` consists of two sections: config-list.h: Documentation/config.adoc config-list.h: Documentation/git-config.adoc config-list.h: Documentation/config/add.adoc config-list.h: Documentation/config/advice.adoc config-list.h: Documentation/config/alias.adoc config-list.h: Documentation/config/am.adoc config-list.h: Documentation/config/apply.adoc ... This first section actually defines on which individual files `config-list.h` depends and thus needs to be rebuild if one of those changes. And the second section contains content like: Documentation/config.adoc: Documentation/git-config.adoc: Documentation/config/add.adoc: Documentation/config/advice.adoc: Documentation/config/alias.adoc: Documentation/config/am.adoc: Documentation/config/apply.adoc: ... These rules exist to ensure Make won't fail with the following error if one of the .adoc files is renamed or removed: make: *** No rule to make target 'Documentation/config.adoc', needed by 'config-list.h'. With the no-op targets defined in `config-list.h.d`, Make knows there's no work to be done to generate these files, so it doesn't error out if it doesn't exist. For the Makefile build system this works great. And since ebeea3c471 (build: regenerate config-list.h when Documentation changes, 2026-02-24) this script is also called from the Meson build system. Nevertheless, on AlmaLinux 8 the following build failure is seen: ninja: error: dependency cycle: config-list.h -> config-list.h This version of this distro uses Ninja 1.8.2 and it seems to have some issues with the format of the `config-list.h.d` file. Ninja versions before 1.10.0 do not reset the depfile parser state on newlines. This causes issues when the depfile has one dependency per line, like we have in `config-list.h.d`: config-list.h: Documentation/config.adoc config-list.h: Documentation/config/add.adoc The parser only recognizes the first "config-list.h:" as a target. On subsequent lines it is still in dependency-parsing mode, so the repeated output name is recorded as an input. This causes the error mentioned above. The bug in Ninja is fixed in 1.10, with commit ninja-build/ninja@1daa7470ab7e (depfile_parser: remove restriction on multiple outputs, 2019-11-20). To be compatible with older versions of Ninja, collapse the dependencies for `config-list.h` into a single line like: config-list.h: Documentation/config.adoc Documentation/config/add.adoc ... This works around the bug in older versions of Ninja, and is fully compatible Make and with more recent versions of Ninja. And while the no-op targets are not needed for Ninja, they also don't do any harm. Helped-by: Patrick Steinhardt Signed-off-by: Toon Claes Signed-off-by: Junio C Hamano

hex: add and use strbuf_add_oid_hex()

2026-05-14T06:59:25Z

Add a function for adding the full hexadecimal hash value of an object ID to a strbuf. It's thread-safe and slightly more efficient than using strbuf_addstr() with oid_to_hex() because it doesn't have to determine the length of the string or copy it from the intermediate static buffer. Add and apply a semantic patch to use it throughout the code base. I get a tiny speedup for git log showing a single hash per commit: Benchmark 1: ./git_main log --format=%H Time (mean ± σ): 91.2 ms ± 0.7 ms [User: 51.9 ms, System: 38.6 ms] Range (min … max): 89.8 ms … 92.6 ms 31 runs Benchmark 2: ./git log --format=%H Time (mean ± σ): 90.5 ms ± 0.7 ms [User: 51.0 ms, System: 38.8 ms] Range (min … max): 89.2 ms … 92.3 ms 32 runs Summary ./git log --format=%H ran 1.01 ± 0.01 times faster than ./git_main log --format=%H Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

Merge branch 'rs/use-strvec-pushv'

2026-04-01T17:28:19Z

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

Merge branch 'jc/rerere-modern-strbuf-handling'

2026-03-27T18:00:03Z

Code clean-up overdue by 19 years. * jc/rerere-modern-strbuf-handling: cocci: strbuf.buf is never NULL rerere: update to modern representation of empty strbufs

Merge branch 'ps/build-tweaks'

2026-03-27T18:00:01Z

Tweak the build infrastructure by moving tools around. * 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

use strvec_pushv() to add another strvec

2026-03-24T19:26:58Z

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

meson: precompile "git-compat-util.h"

2026-03-19T13:40:09Z

Every compilation unit in Git is expected to include "git-compat-util.h" first, either directly or indirectly via "builtin.h". This header papers over differences between platforms so that we can expect the typical POSIX functions to exist. Furthermore, it provides functionality that we end up using everywhere. This header is thus quite heavy as a consequence. Preprocessing it as a standalone unit via `clang -E git-compat-util.h` yields over 23,000 lines of code overall. Naturally, it takes quite some time to compile all of this. Luckily, this is exactly the kind of use case that precompiled headers aim to solve: instead of recompiling it every single time, we compile it once and then link the result into the executable. If include guards are set up properly it means that the file won't need to be reprocessed. Set up such a precompiled header for "git-compat-util.h" and wire it up via Meson. This causes Meson to implicitly include the precompiled header in all compilation units. With GCC and Clang for example this is done via the "-include" statement [1]. This leads to a significant speedup when performing full builds: Benchmark 1: ninja (rev = HEAD~) Time (mean ± σ): 14.467 s ± 0.126 s [User: 248.133 s, System: 31.298 s] Range (min … max): 14.195 s … 14.633 s 10 runs Benchmark 2: ninja (rev = HEAD) Time (mean ± σ): 10.307 s ± 0.111 s [User: 173.290 s, System: 23.998 s] Range (min … max): 10.030 s … 10.433 s 10 runs Summary ninja (rev = HEAD) ran 1.40 ± 0.02 times faster than ninja (rev = HEAD~) [1]: https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

builds: move build scripts into "tools/"

2026-03-19T13:40:09Z

We have a bunch of scripts used by our different build systems that are all located in the top-level directory. Now that we have introduced the new "tools/" directory though we have a better home for them. Move the scripts into the "tools/" directory. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

contrib: move "update-unicode.sh" script into "tools/"

2026-03-19T13:40:09Z

The "update-unicode.sh" script is used to update the unicode data compiled into Git whenever a new version of the Unicode standard has been released. As such, it is a natural part of our developer-facing tooling, and its presence in "contrib/" is misleading. Promote the script into the new "tools/" directory. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano