git/ci, branch jchMirror of https://git.kernel.org/pub/scm/git/git.git/
https://git.shady.money/git/atom?h=jch2026-04-10T00:25:36ZEnable Rust by default2026-04-10T00:25:36Zbrian m. carlsonsandals@crustytoothpaste.net2026-04-09T22:44:34Zurn:sha1:32d5b905909e781786c4735e6bd71503b23e4fb1
Our breaking changes document says that we'll enable Rust by default in
Git 2.54. Adjust the Makefile to switch the option from WITH_RUST to
NO_RUST to enable it by default and update the help text accordingly.
Similarly, for Meson, enable the option by default and do not
automatically disable it if Cargo is missing, since the goal is to help
users find where they are likely to have problems in the future.
Update our CI tests to swap out the single Linux job with Rust to a
single job without, both for Makefile and Meson. Similarly, update the
Windows Makefile job to not use Rust, while the Meson job (which does
not build with ci/lib.sh) will default to having it enabled.
Move the check for Cargo in the Meson build because it is no longer
needed in the main script.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ci: install cargo on Alpine2026-04-10T00:25:36Zbrian m. carlsonsandals@crustytoothpaste.net2026-04-09T22:44:32Zurn:sha1:40c789dfc250486e60b7d7cdba47d8423a754abf
We'll make Rust the default in a future commit, so be sure to install
Cargo (which will also install Rust) to prepare for that case.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'ps/build-tweaks'2026-03-27T18:00:01ZJunio C Hamanogitster@pobox.com2026-03-27T18:00:01Zurn:sha1:d1f07dd50087bef18246feffb963d73b23e2cdd6
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
contrib: move "coccinelle/" directory into "tools/"2026-03-19T13:40:08ZPatrick Steinhardtps@pks.im2026-03-19T05:33:21Zurn:sha1:8ca1b4472ce97ae1d120608f9f02a86fa33d4187
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 <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'ps/ci-reduce-gitlab-envsize'2026-03-10T21:23:21ZJunio C Hamanogitster@pobox.com2026-03-10T21:23:21Zurn:sha1:0f34e8c17441685159c5c0ea5b742bd8257e10ce
CI fix.
* ps/ci-reduce-gitlab-envsize:
ci: unset GITLAB_FEATURES envvar to not bust xargs(1) limits
ci: unset GITLAB_FEATURES envvar to not bust xargs(1) limits2026-03-02T19:08:14ZPatrick Steinhardtps@pks.im2026-03-02T11:55:02Zurn:sha1:eb35167dd4b5f410c261680c8d634bee394eca19
We have started to see the following assert happen in our GitLab CI
pipelines for jobs that use Windows with Meson:
assertion "bc_ctl.arg_max >= LINE_MAX" failed: file "xargs.c", line 512, function: main
The assert in question verifies that we have enough room available to
pass at least `LINE_MAX` many bytes via the command line. The xargs(1)
binary in those jobs comes from Git for Windows, which in turn sources
the binaries from MSYS2, and has the following limits in place:
$ & "C:/Program Files/Git/usr/bin/bash.exe" -l -c 'xargs --show-limits </dev/null'
Your environment variables take up 17373 bytes
POSIX upper limit on argument length (this system): 12579
POSIX smallest allowable upper limit on argument length (all systems): 4096
Maximum length of command we could actually use: 18446744073709546822
Size of command buffer we are actually using: 12579
Maximum parallelism (--max-procs must be no greater): 2147483647
What's interesting to see is the limit of 16 exabits for the maximum
command line length. This value might seem a bit high, and it is indeed
the result of an underflow: our environment is larger than the POSIX
upper limit on argument length, and the value is computed by subtracting
the former from the latter. So what we get is the result of `2^64 -
(17373 - 12579)`.
This makes it clear that the problem here is the size of our environment
variables. A listing sorted by length yields the following result:
$ Get-ChildItem "Env:" |
Sort-Object { $_.Value.Length } -Descending |
Select-Object Name, @{Name="Length"; Expression={$_.Value.Length}}
Name Length
---- ------
GITLAB_FEATURES 6386
Path 706
PSModulePath 229
The GITLAB_FEATURES environment variable makes up for roughly a third of
the complete environment. This variable is a comma-separated list of
features available for the GitLab instance, and seemingly it has been
growing over time as GitLab added more and more features.
Fix the issue by unsetting the environment variable in "ci/lib.sh". This
ensures that the environment variables are now smaller than the upper
limit on argument length again, and that in turn fixes the assert in
xargs(1).
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'ps/ci-gitlab-msvc-updates'2026-02-27T23:11:52ZJunio C Hamanogitster@pobox.com2026-02-27T23:11:52Zurn:sha1:a62d0da86a763ab03604d75eb287776a7d639e1f
CI update.
* ps/ci-gitlab-msvc-updates:
gitlab-ci: handle failed tests on MSVC+Meson job
gitlab-ci: use "run-test-slice-meson.sh"
ci: make test slicing consistent across Meson/Make
github: fix Meson tests not executing at all
meson: fix MERGE_TOOL_DIR with "--no-bin-wrappers"
ci: don't skip smallest test slice in GitLab
ci: handle failures of test-slice helper
ci: make test slicing consistent across Meson/Make2026-02-19T18:22:31ZPatrick Steinhardtps@pks.im2026-02-19T06:25:31Zurn:sha1:2cca4ef34306c04a8ae891e0ea4a876922069dce
In the preceding commit we have adjusted test slicing to be one-based
when using the "ci/run-test-slice.sh" script. But we also have an
equivalent script for Meson that is still zero-based, which is of course
inconsistent.
Adapt the script to be one-based, as well, and adapt the GitHub workflow
accordingly. Note that GitLab doesn't yet use the script, so it does not
need to be adapted. This will change in the next commit though.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ci: handle failures of test-slice helper2026-02-19T18:22:30ZPatrick Steinhardtps@pks.im2026-02-19T06:25:27Zurn:sha1:4a631fee36c2e4daece9af7ff31586678bbf8dac
The "run-test-slice.sh" script executes the test helper to slice up
tests passed to it. As the execution is part of a pipe though, we end up
ignoring any potential error code returned by the helper.
Make the code more robust by storing the tests in a variable first so
that we can split up the pipeline.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ci: ubuntu: use GNU coreutils for dirname2026-02-07T04:58:44ZColin Stagnerask+git@howdoi.land2026-02-07T04:27:03Zurn:sha1:c591c3ceffd0a033eb228ebb54c596362ded5615
The uutils version of `dirname` has output that is inconsistent
with GNU coreutils. Prefer the GNU implementation of this command.
Signed-off-by: Colin Stagner <ask+git@howdoi.land>
Signed-off-by: Junio C Hamano <gitster@pobox.com>