git/.github, branch v2.50.0

Merge branch 'js/github-ci-win-coverity-fix'

2025-06-13T20:29:15Z

Fixes for GitHub Actions Coverity job. * js/github-ci-win-coverity-fix: ci(coverity): output the build log upon error ci(coverity): fix building on Windows

ci(coverity): output the build log upon error

2025-06-11T17:01:14Z

It is quite helpful to know what Coverity said, exactly, in case it fails to analyze the code. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci(coverity): fix building on Windows

2025-06-11T17:01:14Z

When I added the Coverity workflow in a56b6230d0b1 (ci: add a GitHub workflow to submit Coverity scans, 2023-09-25), I merely converted an Azure Pipeline definition that had been running successfully for ages. In the meantime, the current Coverity documentation describes a very different way to install the analysis tool, recommending to add the `bin/` directory to the _end_ of `PATH` (when originally, IIRC, it was recommended to add it to the _beginning_ of the `PATH`). This is crucial! The reason is that the current incarnation of the Windows variant of Coverity's analysis tools come with a _lot_ of DLL files in their `bin/` directory, some of them interferring rather badly with the `gcc.exe` in Git for Windows' SDK that we use to run the Coverity build. The symptom is a cryptic error message: make: *** [Makefile:2960: headless-git.o] Error 1 make: *** Waiting for unfinished jobs.... D:\git-sdk-64-minimal\mingw64\bin\windres.exe: preprocessing failed. make: *** [Makefile:2679: git.res] Error 1 make: *** [Makefile:2893: git.o] Error 1 make: *** [Makefile:2893: builtin/add.o] Error 1 Attempting to detect unconfigured compilers in build |0----------25-----------50----------75---------100| **************************************************** Warning: Build command make.exe exited with code 2. Please verify that the build completed successfully. Warning: Emitted 0 C/C++ compilation units (0%) successfully 0 C/C++ compilation units (0%) are ready for analysis For more details, please look at: D:/a/git/git/cov-int/build-log.txt The log (which the workflow is currently not configured to reveal) then points out that the `windows.h` header cannot be found, which is _still_ not very helpful. The underlying root cause is that the `gcc.exe` in Git for Windows' SDK determines the location of the header files via the location of certain DLL files, and finding the "wrong" ones first on the `PATH` misleads that logic. Let's fix this problem by following Coverity's current recommendation and append the `bin/` directory in which `cov-int` can be found to the _end_ of `PATH`. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'js/ci-build-win-in-release-mode'

2025-05-23T22:34:06Z

win+Meson CI pipeline, unlike other pipelines for Windows, used to build artifacts in develper mode, which has been changed to build them in release mode for consistency. * js/ci-build-win-in-release-mode: ci(win+Meson): build in Release mode

Merge branch 'kn/meson-hdr-check'

2025-05-05T21:56:25Z

Add an equivalent to "make hdr-check" target to meson based builds. * kn/meson-hdr-check: makefile/meson: add 'check-headers' as alias for 'hdr-check' meson: add support for 'hdr-check' meson: rename 'third_party_sources' to 'third_party_excludes' meson: move headers definition from 'contrib/coccinelle' coccinelle: meson: rename variables to be more specific ci/github: install git before checking out the repository

ci(win+Meson): build in Release mode

2025-05-05T15:51:09Z

When the `win+Meson` job was added to Git's CI, modeled after the `win+vs` job, it overlooked that the latter built the Git artifacts in release mode. The reason for this is that there is code in `compat/mingw.c` that turns on the modal assertion dialogs in debug mode, which are very useful when debugging interactively (as they offer to attach Visual Studio's debugger), but they are scarcely useful in CI builds (where that modal dialog would sit around, waiting for a human being to see and deal with it, which obviously won't ever happen). This problem was not realized immediately because of a separate bug: the `win+Meson` job erroneously built using the `gcc` that is in the `PATH` by default on hosted GitHub Actions runners. Since that bug was fixed by switching to `--vsenv`, though, the t7001-mv test consistently timed out after six hours in the CI builds on GitHub, quite often, and wasting build minutes without any benefit in return. The reason for this timeout was a symptom of aforementioned debug mode problem, where the test case 'nonsense mv triggers assertion failure and partially updated index' in t7001-mv triggered an assertion. I originally proposed this here patch to address the timeouts in CI builds. The Git project decided to address this timeout differently, though: by fixing the bug that the t7001-mv test case demonstrated. This does not address the debug mode problem, though, as an `assert()` call could be triggered in other ways in CI, and it should still not cause the CI build to hang but should cause Git to error out instead. To avoid having to accept this here patch, it was then proposed to replace all `assert()` calls in Git's code base by `BUG()` calls. This might be reasonable for independent reasons, but it obviously still does not address the debug mode problem, as `assert()` calls could be easily re-introduced by mistake, and besides, Git has a couple of dependencies that all may have their own `assert()` calls (which are then safely outside the control of the Git project to remove), therefore this here patch is still needed. Signed-off-by: Johannes Schindelin Acked-by: Patrick Steinhardt [jc: rebased on 'maint' to enable fast-tracking the change down] Signed-off-by: Junio C Hamano

Merge branch 'ps/ci-resurrect-p4-on-github'

2025-04-29T21:21:33Z

CI fix. * ps/ci-resurrect-p4-on-github: ci: fix p4d executable not being found on GitHub Actions

ci/github: install git before checking out the repository

2025-04-23T17:34:12Z

The GitHub's CI workflow uses 'actions/checkout@v4' to checkout the repository. This action defaults to using the GitHub REST API to obtain the repository if the `git` executable isn't available. The step to build Git in the GitHub workflow can be summarized as: ... - uses: actions/checkout@v4 #1 - run: ci/install-dependencies.sh #2 ... - run: sudo --preserve-env --set-home --user=builder ci/run-build-and-tests.sh #3 ... Step #1, clones the repository, since the `git` executable isn't present at this step, it uses GitHub's REST API to obtain a tar of the repository. Step #2, installs all dependencies, which includes the `git` executable. Step #3, sets up the build, which includes setting up meson in the meson job. At this point the `git` executable is present. This means while the `git` executable is present, the repository doesn't contain the '.git' folder. To keep both the CI's (GitLab and GitHub) behavior consistent and to ensure that the build is performed on a real-world scenario, install `git` before the repository is checked out. This ensures that 'actions/checkout@v4' will clone the repository instead of using a tarball. We also update the package cache while installing `git`, this is because some distros will fail to locate the package without updating the cache. Helped-by: Phillip Wood Signed-off-by: Karthik Nayak Signed-off-by: Junio C Hamano

ci: fix p4d executable not being found on GitHub Actions

2025-04-22T14:49:16Z

Our tests for git-p4(1) depend on the p4d(1) and p4(1) executables to exist. As we require specific versions of those binaries which typically aren't available on common distributions, we install them manually via "ci/install-dependencies.sh". This script will put the binaries into "$CUSTOM_PATH", which gets defined by "ci/lib.sh" -- if not explicitly overridden, its value will be set to "$HOME/path". This causes issues though when running our tests as unprivileged user, as we do both in GitLab CI and GitHub Actions, because "$HOME" will be different when installing dependencies and when running the tests. Consequently, the downloaded binaries will not be found unless "$CUSTOM_PATH" is overridden to a common location. We already do this for GitLab CI, where it points to "/custom". Let's do the same for GitHub Actions so that Perforce-based tests are executed again. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'ps/misc-build-fixes'

2025-04-16T20:54:18Z

Random build fixes. * ps/misc-build-fixes: ci: use Visual Studio for win+meson job on GitHub Workflows meson: distinguish build and target host binaries meson: respect 'tests' build option in contrib gitweb: fix generation of "gitweb.js" meson: fix handling of '-Dcurl=auto'