git/tools, branch jch

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

contrib: move "coverage-diff.sh" script into "tools/"

2026-03-19T13:40:08Z

The "coverage-diff.sh" script can be used to get information about test coverage fro the Git codebase. It is thus rather specific to our build and test infrastructure and part of the developer-facing tooling. The fact that this script is part of "contrib/" is thus rather misleading and a historic wart. Promote the tool into the new "tools/" directory. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

contrib: move "coccinelle/" directory into "tools/"

2026-03-19T13:40:08Z

The Coccinelle tool is an ingrained part of our build infrastructure. It is executed by our CI to detect antipatterns and is used to detect misuses of certain interfaces. It's presence in "contrib/" is thus rather misleading. Promote the configuration into the new "tools/" directory. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Introduce new "tools/" directory

2026-03-19T13:40:08Z

According to its readme, the "contrib/" directory's main intent is to collect stuff that is not an official part of Git, either because it is too specialized or because it is still considered experimental. The reality tells a bit of a different story though: while it _does_ contain such things, it also contains other things: - Our credential helpers, which are being distributed by many packagers nowadays and which can be considered "stable". - A bunch of tooling that relates to our build and test infrastructure. Especially the second category is somewhat of a sore spot. You really wouldn't expect build-related tooling to be considered an optional part of Git. Quite the opposite. Create a new top-level "tools/" directory to fix this discrepancy. This directory will contain all kind of tools that are related to our build infrastructure and that Git developers are likely to use day to day. For now, this directory doesn't contain anything yet except for a readme and a Meson skeleton. This will change in subsequent commits. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano