git/ci, branch v2.47.2

Merge branch 'jk/ci-linux32-update'

2024-09-16T22:27:08Z

CI updates * jk/ci-linux32-update: ci: add Ubuntu 16.04 job to GitLab CI ci: use regular action versions for linux32 job ci: use more recent linux32 image ci: unify ubuntu and ubuntu32 dependencies ci: drop run-docker scripts

ci: add Ubuntu 16.04 job to GitLab CI

2024-09-13T16:02:30Z

In the preceding commits we had to convert the linux32 job to be based on Ubuntu 20.04 instead of Ubuntu 16.04 due to a limitation in GitHub Workflows. This was the only job left that still tested against this old but supported Ubuntu version, and we have no other jobs that test with a comparatively old Linux distribution. Add a new job to GitLab CI that tests with Ubuntu 16.04 to cover the resulting test gap. GitLab doesn't modify Docker images in the same way GitHub does and thus doesn't fall prey to the same issue. There are two compatibility issues uncovered by this: - Ubuntu 16.04 does not support HTTP/2 in Apache. We thus cannot set `GIT_TEST_HTTPD=true`, which would otherwise cause us to fail when Apache fails to start. - Ubuntu 16.04 cannot use recent JGit versions as they depend on a more recent Java runtime than we have available. We thus disable installing any kind of optional dependencies that do not come from the package manager. These two restrictions are fine though, as we only really care about whether Git compiles and runs on such old distributions in the first place. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

ci: use more recent linux32 image

2024-09-12T17:21:10Z

The Xenial image we're using was released more than 8 years ago. This is a problem for using some recent GitHub Actions scripts, as they require Node.js 20, and all of the binaries they ship need glibc 2.28 or later. We're not using them yet, but moving forward prepares us for a future patch which will. Xenial was actually the last official 32-bit Ubuntu release, but you can still find i386 images for more recent releases. This patch uses Focal, which was released in 2020 (and is the oldest one with glibc 2.28). There are two small downsides here: - while Xenial is pretty old, it is still in LTS support until April 2026. So there's probably some value in testing with such an old system, and we're losing that. - there are no i386 subversion packages in the Focal repository. So we won't be able to test that (OTOH, we had never tested it until the previous patch which unified the 32/64-bit dependency code). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

ci: unify ubuntu and ubuntu32 dependencies

2024-09-12T17:21:10Z

The script to install dependencies has two separate entries for 32-bit and 64-bit Ubuntu systems. This increases the maintenance burden since both should need roughly the same packages. That hasn't been too bad so far because we've stayed on the same 32-bit image since 2017. Trying to move to a newer image revealed several problems with the linux32 job: - newer images complain about using "linux32 --32bit i386", due to seccomp restrictions. We can loosen these with a docker option, but I don't think running it is even doing anything. We use it only for pretending to "apt" that we're on a 32-bit machine, but inside the container image apt is already configured as a 32-bit system (even though the kernel outside the container is obviously 64-bit). Using the same apt invocation for both architectures just gets rid of this call entirely. - we set DEBIAN_FRONTEND to avoid hanging on packages that ask the user questions. This wasn't a problem on the old image, but it is on newer ones. The 64-bit stanza handles this already. As a bonus, the 64-bit stanza uses "apt -q" instead of redirecting output to /dev/null. This would have saved me a lot of debugging time trying to figure out why it was hanging. :) - the old image seems to have zlib-dev installed by default, but newer ones do not. In addition, there were probably many tests being skipped on the 32-bit build because we didn't have support packages installed (e.g., gpg). Now we'll run them. We do need to keep some parts split off just for 64-bit systems: our p4 and lfs installs reference x86_64/amd64 binaries. The downloaded jgit should work in theory, since it's just a jar file embedded in a shell script that relies on the system java. But the system java in our image is too old, so I've left it as 64-bit only for now. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

ci: drop run-docker scripts

2024-09-12T17:21:10Z

We haven't used these scripts since 4a6e4b9602 (CI: remove Travis CI support, 2021-11-23), as the GitHub Actions config has support for directly running jobs within docker containers. It's possible we might want to resurrect something like this in order to be more agnostic to the CI platform. But it's not clear exactly what it would look like. And in the meantime, it's just a maintenance burden as we make changes to CI config, and is subject to bitrot. In fact it's already broken; it references ci/install-docker-dependencies.sh, which went away in 9cdeb34b96 (ci: merge scripts which install dependencies, 2024-04-12). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'tb/incremental-midx-part-1'

2024-08-19T18:07:37Z

Incremental updates of multi-pack index files. * tb/incremental-midx-part-1: midx: implement support for writing incremental MIDX chains t/t5313-pack-bounds-checks.sh: prepare for sub-directories t: retire 'GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP' midx: implement verification support for incremental MIDXs midx: support reading incremental MIDX chains midx: teach `midx_fanout_add_midx_fanout()` about incremental MIDXs midx: teach `midx_preferred_pack()` about incremental MIDXs midx: teach `midx_contains_pack()` about incremental MIDXs midx: remove unused `midx_locate_pack()` midx: teach `fill_midx_entry()` about incremental MIDXs midx: teach `nth_midxed_offset()` about incremental MIDXs midx: teach `bsearch_midx()` about incremental MIDXs midx: introduce `bsearch_one_midx()` midx: teach `nth_bitmapped_pack()` about incremental MIDXs midx: teach `nth_midxed_object_oid()` about incremental MIDXs midx: teach `prepare_midx_pack()` about incremental MIDXs midx: teach `nth_midxed_pack_int_id()` about incremental MIDXs midx: add new fields for incremental MIDX chains Documentation: describe incremental MIDX format

Merge branch 'ps/p4-tests-updates'

2024-08-08T17:41:21Z

Perforce tests have been updated. * ps/p4-tests-updates: t98xx: mark Perforce tests as memory-leak free ci: update Perforce version to r23.2 t98xx: fix Perforce tests with p4d r23 and newer

midx: implement support for writing incremental MIDX chains

2024-08-06T19:01:39Z

Now that the rest of the MIDX subsystem and relevant callers have been updated to learn about how to read and process incremental MIDX chains, let's finally update the implementation in `write_midx_internal()` to be able to write incremental MIDX chains. This new feature is available behind the `--incremental` option for the `multi-pack-index` builtin, like so: $ git multi-pack-index write --incremental The implementation for doing so is relatively straightforward, and boils down to a handful of different kinds of changes implemented in this patch: - The `compute_sorted_entries()` function is taught to reject objects which appear in any existing MIDX layer. - Functions like `write_midx_revindex()` are adjusted to write pack_order values which are offset by the number of objects in the base MIDX layer. - The end of `write_midx_internal()` is adjusted to move non-incremental MIDX files when necessary (i.e. when creating an incremental chain with an existing non-incremental MIDX in the repository). There are a handful of other changes that are introduced, like new functions to clear incremental MIDX files that are unrelated to the current chain (using the same "keep_hash" mechanism as in the non-incremental case). The tests explicitly exercising the new incremental MIDX feature are relatively limited for two reasons: 1. Most of the "interesting" behavior is already thoroughly covered in t5319-multi-pack-index.sh, which handles the core logic of reading objects through a MIDX. The new tests in t5334-incremental-multi-pack-index.sh are mostly focused on creating and destroying incremental MIDXs, as well as stitching their results together across layers. 2. A new GIT_TEST environment variable is added called "GIT_TEST_MULTI_PACK_INDEX_WRITE_INCREMENTAL", which modifies the entire test suite to write incremental MIDXs after repacking when combined with the "GIT_TEST_MULTI_PACK_INDEX" variable. This exercises the long tail of other interesting behavior that is defined implicitly throughout the rest of the CI suite. It is likewise added to the linux-TEST-vars job. Signed-off-by: Taylor Blau Signed-off-by: Junio C Hamano

t: retire 'GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP'

2024-08-06T19:01:38Z

Two years ago, commit ff1e653c8e2 (midx: respect 'GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP', 2021-08-31) introduced a new environment variable which caused the test suite to write MIDX bitmaps after any 'git repack' invocation. At the time, this was done to help flush out any bugs with MIDX bitmaps that weren't explicitly covered in the t5326-multi-pack-bitmap.sh script. Two years later, that flag has served us well and is no longer providing meaningful coverage, as the script in t5326 has matured substantially and covers many more interesting cases than it did back when ff1e653c8e2 was originally written. Remove the 'GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP' environment variable as it is no longer serving a useful purpose. More importantly, removing this variable clears the way for us to introduce a new one to help similarly flush out bugs related to incremental MIDX chains. Because these incremental MIDX chains are (for now) incompatible with MIDX bitmaps, we cannot have both. Signed-off-by: Taylor Blau Signed-off-by: Junio C Hamano

Merge branch 'kn/ci-clang-format'

2024-07-31T20:34:18Z

A CI job that use clang-format to check coding style issues in new code has been added. * kn/ci-clang-format: ci/style-check: add `RemoveBracesLLVM` in CI job check-whitespace: detect if no base_commit is provided ci: run style check on GitHub and GitLab clang-format: formalize some of the spacing rules clang-format: avoid spacing around bitfield colon clang-format: indent preprocessor directives after hash