user/sven/git.git/gitweb, branch v2.49.0-rc2

Merge branch 'ps/build'

2024-12-16T01:54:33Z

Build procedure update plus introduction of Meson based builds. * ps/build: (24 commits) Introduce support for the Meson build system Documentation: add comparison of build systems t: allow overriding build dir t: better support for out-of-tree builds Documentation: extract script to generate a list of mergetools Documentation: teach "cmd-list.perl" about out-of-tree builds Documentation: allow sourcing generated includes from separate dir Makefile: simplify building of templates Makefile: write absolute program path into bin-wrappers Makefile: allow "bin-wrappers/" directory to exist Makefile: refactor generators to be PWD-independent Makefile: extract script to generate gitweb.js Makefile: extract script to generate gitweb.cgi Makefile: extract script to massage Python scripts Makefile: extract script to massage Shell scripts Makefile: use "generate-perl.sh" to massage Perl library Makefile: extract script to massage Perl scripts Makefile: consistently use PERL_PATH Makefile: generate doc versions via GIT-VERSION-GEN Makefile: generate "git.rc" via GIT-VERSION-GEN ...

Merge branch 'jc/forbid-head-as-tagname'

2024-12-16T01:54:26Z

"git tag" has been taught to refuse to create refs/tags/HEAD as such a tag will be confusing in the context of UI provided by the Git Porcelain commands. * jc/forbid-head-as-tagname: tag: "git tag" refuses to use HEAD as a tagname t5604: do not expect that HEAD can be a valid tagname refs: drop strbuf_ prefix from helpers refs: move ref name helpers around

Introduce support for the Meson build system

2024-12-06T22:52:14Z

Introduce support for the Meson build system, a "modern" meta build system that supports many different platforms, including Linux, macOS, Windows and BSDs. Meson supports different backends, including Ninja, Xcode and Microsoft Visual Studio. Several common IDEs provide an integration with it. The biggest contender compared to Meson is probably CMake as outlined in our "Documentation/technical/build-systems.txt" file. Based on my own personal experience from working with both build systems extensively I strongly favor Meson over CMake. In my opinion, it feels significantly easier to use with a syntax that feels more like a "real" programming language. The second big reason is that Meson supports Rust natively, which may prove to be important given that the project may pick up Rust as another language eventually. Using Meson is rather straight-forward. An example: ``` # Meson uses out-of-tree builds. You can set up multiple build # directories, how you name them is completely up to you. $ mkdir build $ cd build $ meson setup .. -Dprefix=/tmp/git-installation # Build the project. This also provides several other targets like e.g. `install` or `test`. $ ninja # Meson has been wired up to support execution of our test suites. # Both our unit tests and our integration tests are supported. # Running `meson test` without any arguments will execute all tests, # but the syntax supports globbing to select only some tests. $ meson test 't-*' # Execute single test interactively to allow for debugging. $ meson test 't0000-*' --interactive --test-args=-ix ``` The build instructions have been successfully tested on the following systems, tests are passing: - Apple macOS 10.15. - FreeBSD 14.1. - NixOS 24.11. - OpenBSD 7.6. - Ubuntu 24.04. - Windows 10 with Cygwin. - Windows 10 with MinGW64, except for t9700, which is also broken with our Makefile. - Windows 10 with Visual Studio 2022 toolchain, using the Native Tools Command Prompt with `meson setup --vsenv`. Tests pass, except for t9700. - Windows 10 with Visual Studio 2022 solution, using the Native Tools Command Prompt with `meson setup --backend vs2022`. Tests pass, except for t9700. - Windows 10 with VS Code, using the Meson plug-in. It is expected that there will still be rough edges in the current version. If this patch lands the expectation is that it will coexist with our other build systems for a while. Like this, distributions can slowly migrate over to Meson and report any findings they have to us such that we can continue to iterate. A potential cutoff date for other build systems may be Git 3.0. Some notes: - The installed distribution is structured somewhat differently than how it used to be the case. All of our binaries are installed into `$libexec/git-core`, while all binaries part of `$bindir` are now symbolic links pointing to the former. This rule is consistent in itself and thus easier to reason about. - We do not install dashed binaries into `$libexec/git-core` anymore, so there won't e.g. be a symlink for git-add(1). These are not required by modern Git and there isn't really much of a use case for those anymore. By not installing those symlinks we thus start the deprecation of this layout. - We're targeting Meson 1.3.0, which has been released relatively recently November 2023. The only feature we use from that version is `fs.relative_to()`, which we could replace if necessary. If so, we could start to target Meson 1.0.0 and newer, released in December 2022. - The whole build instructions count around 3300 lines, half of which is listing all of our code and test files. Our Makefiles are around 5000 lines, autoconf adds another 1300 lines. CMake in comparison has only 1200 linescode, but it avoids listing individual files and does not wire up auto-configuration as extensively as the Meson instructions do. - We bundle a set of subproject wrappers for curl, expat, openssl, pcre2 and zlib. This allows developers to build Git without these dependencies preinstalled, and Meson will fetch and build them automatically. This is especially helpful on Windows. Helped-by: Eli Schwartz Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Makefile: extract script to generate gitweb.js

2024-12-06T22:52:11Z

Similar to the preceding commit, also extract the script to generate the "gitweb.js" file. While the logic itself is trivial, it helps us avoid duplication of logic across build systems and ensures that the build systems will remain in sync with each other in case the logic ever needs to change. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Makefile: extract script to generate gitweb.cgi

2024-12-06T22:52:11Z

In order to generate "gitweb.cgi" we have to replace various different placeholders. This is done ad-hoc and is thus not easily reusable across different build systems. Introduce a new GITWEB-BUILD-OPTIONS.in template that we populate at configuration time with the expected options. This script is then used as input for a new "generate-gitweb.sh" script that generates the final "gitweb.cgi" file. While this requires us to repeat the options multiple times, it is in line to how we generate other build options like our GIT-BUILD-OPTIONS file. While at it, refactor how we replace the GITWEB_PROJECT_MAXDEPTH. Even though this variable is supposed to be an integer, the source file has the value quoted. The quotes are eventually stripped via sed(1), which replaces `"@GITWEB_PROJECT_MAXDEPTH@"` with the actual value, which is rather nonsensical. This is made clearer by just dropping the quotes in the source file. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Makefile: consistently use @PLACEHOLDER@ to substitute

2024-12-06T22:52:08Z

We have a bunch of placeholders in our scripts that we replace at build time, for example by using sed(1). These placeholders come in three different formats: @PLACEHOLDER@, @@PLACEHOLDER@@ and ++PLACEHOLDER++. Next to being inconsistent it also creates a bit of a problem with CMake, which only supports the first syntax in its `configure_file()` function. To work around that we instead manually replace placeholders via string operations, which is a hassle and removes safeguards that CMake has to verify that we didn't forget to replace any placeholders. Besides that, other build systems like Meson also support the CMake syntax. Unify our codebase to consistently use the syntax supported by such build systems. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

refs: drop strbuf_ prefix from helpers

2024-12-03T03:38:49Z

The helper functions (strbuf_branchname, strbuf_check_branch_ref, and strbuf_check_tag_ref) are about handling branch and tag names, and it is a non-essential fact that these functions use strbuf to hold these names. Rename them to make it clarify that these are more about "ref". Signed-off-by: Junio C Hamano

gitweb: make use of s///r

2024-10-23T20:16:36Z

In Perl 5.14, released in May 2011, the r modifier was added to the s/// operator to allow it to return the modified string instead of modifying the string in place. This allows to write nicer, more succinct code in several cases, so let's do that here. Signed-off-by: brian m. carlson Signed-off-by: Taylor Blau

Require Perl 5.26.0

2024-10-23T20:16:36Z

Our platform support policy states that we require "versions of dependencies which are generally accepted as stable and supportable, e.g., in line with the version used by other long-term-support distributions". Of Debian, Ubuntu, RHEL, and SLES, the four most common distributions that provide LTS versions, the version with mainstream long-term security support with the oldest Perl is 5.26.0 in SLES 15.6. This is a major upgrade, since Perl 5.8.1, according to the Perl documentation, was released in September of 2003. It brings a lot of new features that we can choose to use, such as s///r to return the modified string, the postderef functionality, and subroutine signatures, although the latter was still considered experimental until 5.36. This change was made with the following one-liner, which intentionally excludes modifying the vendored modules we include to avoid conflicts: git grep -l 'use 5.008001' | grep -v 'LoadCPAN/' | xargs perl -pi -e 's/use 5.008001/require v5.26/' Use require instead of use to avoid changing the behavior as the latter enables features and the former does not. Signed-off-by: brian m. carlson Signed-off-by: Taylor Blau

Merge branch 'am/gitweb-feed-use-committer-date'

2024-07-15T17:11:41Z

GitWeb update to use committer date consistently in rss/atom feeds. * am/gitweb-feed-use-committer-date: gitweb: rss/atom change published/updated date to committer date