git/templates, branch maint

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

Makefile: set default goals in makefiles

2025-02-18T17:02:26Z

Explicitly set the default goal at the very top of various makefiles. This is already present in some makefiles, but not all of them. In particular, this corrects a regression introduced in a38edab7c8 (Makefile: generate doc versions via GIT-VERSION-GEN, 2024-12-06). That commit added some config files as build targets for the Documentation directory, and put the target configuration in a sensible place. Unfortunately, that sensible place was above any other build target definitions, meaning the default goal changed to being those configuration files only, rather than the HTML and man page documentation. Signed-off-by: Adam Dinwoodie Helped-by: Junio C Hamano Acked-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

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: simplify building of templates

2024-12-06T22:52:12Z

When we install Git we also install a set of default templates that both git-init(1) and git-clone(1) populate into our build directories. The way the pristine templates are laid out in our source directory is somewhat weird though: instead of reconstructing the actual directory hierarchy in "templates/", we represent directory separators with "--". The only reason I could come up with for why we have this is the "branches/" directory, which is supposed to be empty when installing it. And as Git famously doesn't store empty directories at all we have to work around this limitation. Now the thing is that the "branches/" directory is a leftover to how branches used to be stored in the dark ages. gitrepository-layout(5) lists this directory as "slightly deprecated", which I would claim is a strong understatement. I have never encountered anybody using it today and would be surprised if it even works as expected. So having the "--" hack in place for an item that is basically unused, unmaintained and deprecated doesn't only feel unreasonable, but installing that entry by default may also cause confusion for users that do not know what this is supposed to be in the first place. Remove this directory from our templates and, now that we do not require the workaround anymore, restructure the templates to form a proper hierarchy. This makes it way easier for build systems to install these templates into place. We should likely think about removing support for "branch/" altogether, but that is outside of the scope of this patch series. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'jp/use-diff-index-in-pre-commit-sample'

2023-12-20T18:14:52Z

The sample pre-commit hook that tries to catch introduction of new paths that use potentially non-portable characters did not notice an existing path getting renamed to such a problematic path, when rename detection was enabled. * jp/use-diff-index-in-pre-commit-sample: hooks--pre-commit: detect non-ASCII when renaming

hooks--pre-commit: detect non-ASCII when renaming

2023-12-03T02:55:40Z

When diff.renames is turned on, the diff-filter will not return renamed files (or copied ones with diff.renames=copy) and potential non-ASCII characters would not be caught by this hook. Use the plumbing command diff-index instead of the porcelain one to not be affected by diff.rename. Signed-off-by: Julian Prein Signed-off-by: Junio C Hamano

send-email: export patch counters in validate environment

2023-04-14T17:41:15Z

When sending patch series (with a cover-letter or not) sendemail-validate is called with every email/patch file independently from the others. When one of the patches depends on a previous one, it may not be possible to use this hook in a meaningful way. A hook that wants to check some property of the whole series needs to know which patch is the final one. Expose the current and total number of patches to the hook via the GIT_SENDEMAIL_PATCH_COUNTER and GIT_SENDEMAIL_PATCH_TOTAL environment variables so that both incremental and global validation is possible. Sharing any other state between successive invocations of the validate hook must be done via external means. For example, by storing it in a git config sendemail.validateWorktree entry. Add a sample script with placeholder validations and update tests to check that the counters are properly exported. Suggested-by: Phillip Wood Signed-off-by: Robin Jarry Signed-off-by: Junio C Hamano

fsmonitor: query watchman with right valid json

2022-06-07T17:00:49Z

In rare circumstances where the current git index does not carry the last_update_token, the fsmonitor v2 hook will be invoked with an empty string which would caused the final rendered json to be invalid. ["query", "/path/to/my/git/repository/", { "since": , "fields": ["name"], "expression": ["not", ["dirname", ".git"]] }] Which will left user with the following error message > git status failed to parse command from stdin: line 2, column 13, position 67: unexpected token near ',' Watchman: command returned no output. Falling back to scanning... Hide the "since" field in json query when "last_update_token" is empty. Co-authored-by: Ævar Arnfjörð Bjarmason Signed-off-by: Son Luong Ngoc Signed-off-by: Junio C Hamano

Makefile: add "$(QUIET)" boilerplate to shared.mak

2022-03-03T22:14:55Z

The $(QUIET) variables we define are largely duplicated between our various Makefiles, let's define them in the new "shared.mak" instead. Since we're not using the environment to pass these around we don't need to export the "QUIET_GEN" and "QUIET_BUILT_IN" variables anymore. The "QUIET_GEN" variable is used in "git-gui/Makefile" and "gitweb/Makefile", but they've got their own definition for those. The "QUIET_BUILT_IN" variable is only used in the top-level "Makefile". We still need to export the "V" variable. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Makefiles: add "shared.mak", move ".DELETE_ON_ERROR" to it

2022-03-03T22:14:55Z

We have various behavior that's shared across our Makefiles, or that really should be (e.g. via defined templates). Let's create a top-level "shared.mak" to house those sorts of things, and start by adding the ".DELETE_ON_ERROR" flag to it. See my own 7b76d6bf221 (Makefile: add and use the ".DELETE_ON_ERROR" flag, 2021-06-29) and db10fc6c09f (doc: simplify Makefile using .DELETE_ON_ERROR, 2021-05-21) for the addition and use of the ".DELETE_ON_ERROR" flag. I.e. this changes the behavior of existing rules in the altered Makefiles (except "Makefile" & "Documentation/Makefile"). I'm confident that this is safe having read the relevant rules in those Makfiles, and as the GNU make manual notes that it isn't the default behavior is out of an abundance of backwards compatibility caution. From edition 0.75 of its manual, covering GNU make 4.3: [Enabling '.DELETE_ON_ERROR' is] almost always what you want 'make' to do, but it is not historical practice; so for compatibility, you must explicitly request it. This doesn't introduce a bug by e.g. having this ".DELETE_ON_ERROR" flag only apply to this new shared.mak, Makefiles have no such scoping semantics. It does increase the danger that any Makefile without an explicit "The default target of this Makefile is..." snippet to define the default target as "all" could have its default rule changed if our new shared.mak ever defines a "real" rule. In subsequent commits we'll be careful not to do that, and such breakage would be obvious e.g. in the case of "make -C t". We might want to make that less fragile still (e.g. by using ".DEFAULT_GOAL" as noted in the preceding commit), but for now let's simply include "shared.mak" without adding that boilerplate to all the Makefiles that don't have it already. Most of those are already exposed to that potential caveat e.g. due to including "config.mak*". Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano