git/gitweb, branch master

gitweb: let page header grow on mobile for long wrapped project names

2026-02-17T19:49:13Z

On mobile, long project names in the page header can wrap to multiple lines, but the fixed 25px header height does not grow with wrapped content. Switch the header from fixed height to min-height so it expands as needed while keeping the same baseline height for single-line titles. Signed-off-by: Rito Rhymes Signed-off-by: Junio C Hamano

gitweb: fix mobile footer overflow by wrapping text and clearing floats

2026-02-17T19:49:13Z

On narrow screens, footer text can wrap, but the fixed 22px footer height and floated footer blocks can cause overflow. Switch to min-height and add a clearfix on the footer container so it grows to contain wrapped float content cleanly. Signed-off-by: Rito Rhymes Signed-off-by: Junio C Hamano

gitweb: fix mobile page overflow across log/commit/blob/diff views

2026-02-17T19:49:12Z

On mobile-sized viewports, gitweb pages in log/commit/blob/diff views can overflow horizontally due to desktop-oriented paddings and fixed-width preformatted content. Extend the existing mobile media query to rebalance those layouts: reduce or clear paddings in log/commit sections, and allow horizontal scrolling for preformatted blob/diff content instead of forcing page-wide overflow. All layout adjustments in this patch are mobile-scoped, except one global safeguard: set overflow-wrap:anywhere on div.log_body. Log content can contain escaped or non-breaking text that behaves like a single long token and can overflow at any viewport width, including desktop. Signed-off-by: Rito Rhymes Signed-off-by: Junio C Hamano

gitweb: prevent project search bar from overflowing on mobile

2026-02-17T19:49:12Z

On narrow screens, the project search input can exceed the available width and force page-wide horizontal scrolling. Add a mobile media query and apply side padding to the search container, then cap the input width to its container with border-box sizing so the form stays within the viewport. Signed-off-by: Rito Rhymes Signed-off-by: Junio C Hamano

gitweb: add viewport meta tag for mobile devices

2026-02-17T19:49:12Z

Without a viewport meta tag, phone browsers render gitweb at desktop width and scale the whole page down to fit the screen. Add a viewport meta tag so the layout viewport tracks device width. This is the baseline needed for mobile CSS fixes in follow-up commits. Signed-off-by: Rito Rhymes Signed-off-by: Junio C Hamano

meson: distinguish build and target host binaries

2025-04-01T09:20:44Z

Almost all of the tools we discover during the build process need to be native programs. There are only a handful of exceptions, which typically are programs whose paths we need to embed into the resulting executable so that they can be found on the target system when Git executes. While this distinction typically doesn't matter, it does start to matter when considering cross-compilation where the build and target machines are different. Meson supports cross-compilation via so-called machine files. These machine files allow the user to override parameters for the build machine, but also for the target machine when cross-compiling. Part of the machine file is a section that allows the user to override the location where binaries are to be found in the target system. The following machine file would for example override the path of the POSIX shell: [binaries] sh = '/usr/xpg4/bin/sh' It can be handed over to Meson via `meson setup --cross-file`. We do not handle this correctly right now though because we don't know to distinguish binaries for the build and target hosts at all. Address this by explicitly passing the `native:` parameter to `find_program()`: - When set to `true`, we get binaries discovered on the build host. - When set to `false`, we get either the path specified in the machine file. Or, if no machine file exists or it doesn't specify the binary path, then we fall back to the binary discovered on the build host. As mentioned, only a handful of binaries are not native: only the system shell, Python and Perl need to be treated specially here. Reported-by: Peter Seiderer Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

gitweb: fix generation of "gitweb.js"

2025-04-01T09:20:44Z

In 19d8fe7da65 (Makefile: extract script to generate gitweb.js, 2024-12-06) we have extracted the logic to build "gitweb.js" into a separate script. As part of that the rules that builds the script has gained a new dependency on that script. This refactoring is broken though because we use "$^" to determine the set of JavaScript files that need to be concatenated, and this implicit variable now also contains the build script itself. As a result, the build script ends up ni the generated "gitweb.js" file, which is wrong. Fix the issue by filtering out non-JavaScript files. Based-on-patch-by: Thorsten Glaser Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

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