Fork of git SCM with my patches. http://git.kilabit.info/git/atom?h=main 2026-03-02T19:08:14Z 2026-03-02T19:08:14Z Patrick Steinhardt ps@pks.im 2026-03-02T11:55:02Z urn: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> 2026-01-19T19:02:31Z Junio C Hamano gitster@pobox.com 2026-01-17T18:34:17Z urn:sha1:047bd7dfe3b6563ea5f6543533207e3481f3e74c Looking at the CI logs, the p4 and cvs tests account for another 24 minutes of test time and they offer minimal value for quite a similar reason as the previous step. Let's introduce and use a mechanism to skip these tests to save some resources. Suggested-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2026-01-17T18:23:59Z Johannes Schindelin johannes.schindelin@gmx.de 2026-01-16T17:31:16Z urn:sha1:d7971544fe17378f44f49983010dbfc1834f7bef I noticed recently that the leak-checking jobs still take a lot of time, and upon analysis, the git-svn tests contribute significantly to this. Analyzing a recent CI run, I saw that the Git test suite contains 1,017 tests, running for approximately 5¼ hours total. Of these, 65 git-svn-related tests (~6% of test count) took 42.24 minutes combined, accounting for ~13.% of the total runtime. This implies that the git-svn tests are roughly twice as expernsive compared to the other tests. However, testing git-svn in the leak-checking jobs provides minimal value: git-svn is implemented as a Perl script, and leak checking only handles C code. While git-svn does call into Git's built-in commands that are implemented in C, these are standard Git operations that are already thoroughly exercised elsewhere in the test suite. Therefore, running the git-svn tests in the leak-checking jobs only adds to the overall run time with little value in return. Given that the leak-checking jobs are particularly time-intensive and these 42+ minutes of SVN tests per job provide no additional leak detection value, skip them in the *-leaks jobs to reduce CI runtime. Assisted-by: Claude Sonnet 4.5 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2025-02-20T15:49:52Z Patrick Steinhardt ps@pks.im 2025-02-18T07:46:00Z urn:sha1:63a597dd94079887a1b5ad72f64a8b0ee822dc27 Wire up credential helpers in our CI runs so that we can rest assured that they compile and (if tests are available) function correctly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2025-02-20T15:49:52Z Patrick Steinhardt ps@pks.im 2025-02-18T07:45:59Z urn:sha1:235fe77c2990ca6762ad9146105915987acf956d The musl-based Meson job is supposed to explicitly specify the UTF-8 locale used for testing, which has been introduced with 84bb5eeace7 (ci: switch linux-musl to use Meson, 2025-01-28). That commit had two issues though: - We continue to refer to "linux-musl", even though the job has been renamed in the same commit to "linux-musl-meson". - We use the wrong option name to specify the locale. This was not noticed though due to the first issue. Fix both of these issues by fixing both the job and option naems. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2025-02-06T22:56:45Z Junio C Hamano gitster@pobox.com 2025-02-06T22:56:45Z urn:sha1:9d0e81e2ae3bd7f6d8a655be53c2396d7af3d2b0 The code paths to interact with zlib has been cleaned up in preparation for building with zlib-ng. * ps/zlib-ng: ci: make "linux-musl" job use zlib-ng ci: switch linux-musl to use Meson compat/zlib: allow use of zlib-ng as backend git-zlib: cast away potential constness of `next_in` pointer compat/zlib: provide stubs for `deflateSetHeader()` compat/zlib: provide `deflateBound()` shim centrally git-compat-util: move include of "compat/zlib.h" into "git-zlib.h" compat: introduce new "zlib.h" header git-compat-util: drop `z_const` define compat: drop `uncompress2()` compatibility shim 2025-02-06T22:56:44Z Junio C Hamano gitster@pobox.com 2025-02-06T22:56:44Z urn:sha1:2bf3c7fab19a59cde3a3dda9398075f0fe8d57c1 CI updates (containerization, dropping stale ones, etc.). * ps/ci-misc-updates: ci: remove stale code for Azure Pipelines ci: use latest Ubuntu release ci: stop special-casing for Ubuntu 16.04 gitlab-ci: add linux32 job testing against i386 gitlab-ci: remove the "linux-old" job github: simplify computation of the job's distro github: convert all Linux jobs to be containerized github: adapt containerized jobs to be rootless t7422: fix flaky test caused by buffered stdout t0060: fix EBUSY in MinGW when setting up runtime prefix 2025-02-03T18:23:33Z Junio C Hamano gitster@pobox.com 2025-02-03T18:23:33Z urn:sha1:803b5acaa7cb979b5d623270af18d6d8354fce9b Following the procedure we established to introduce breaking changes for Git 3.0, allow an early opt-in for removing support of $GIT_DIR/branches/ and $GIT_DIR/remotes/ directories to configure remotes. * ps/3.0-remote-deprecation: remote: announce removal of "branches/" and "remotes/" builtin/pack-redundant: remove subcommand with breaking changes ci: repurpose "linux-gcc" job for deprecations ci: merge linux-gcc-default into linux-gcc Makefile: wire up build option for deprecated features 2025-01-28T21:03:23Z Patrick Steinhardt ps@pks.im 2025-01-28T08:41:35Z urn:sha1:84bb5eeace7f797c3898ad6ee6c4909200be0c77 Switch over the "linux-musl" job to use Meson instead of Makefiles. This is done due to multiple reasons: - It simplifies our CI infrastructure a bit as we don't have to manually specify a couple of build options anymore. - It verifies that Meson detects and sets those build options automatically. - It makes it easier for us to wire up a new CI job using zlib-ng as backend. One platform compatibility that Meson cannot easily detect automatically is the `GIT_TEST_UTF8_LOCALE` variable used in tests. Wire up a build option for it, which we set via a new "MESONFLAGS" environment variable. Note that we also drop the CC variable, which is set to "gcc". We already default to GCC when CC is unset in "ci/lib.sh", so this is not needed. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2025-01-22T20:28:27Z Patrick Steinhardt ps@pks.im 2025-01-22T11:31:30Z urn:sha1:04c29bdea04e5af5193fd386b62a48c320351f19 The "linux-gcc-default" job is mostly doing the same as the "linux-gcc" job, except for a couple of minor differences: - We use an explicit GCC version instead of the default version provided by the distribution. We have other jobs that test with "gcc-8", making this distinction pointless. - We don't set up the Python version explicitly, and instead use the default Python version. Python 2 has been end-of-life for quite a while now though, making this distinction less interesting. - We set up the default branch name to be "main" in "linux-gcc". We have other testcases that don't and also some that explicitly use "master". - We use "ubuntu:20.04" in one job and "ubuntu:latest" in another. We already have a couple other jobs testing these respectively. So overall, the job does not add much to our test coverage. Drop the "linux-gcc-default" job and adapt "linux-gcc" to start using the default GCC compiler, effectively merging those two jobs into one. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>