path: root/contrib/buildsystems/CMakeLists.txt
AgeCommit message (Collapse)Author
2022-11-08Makefile & test-tool: replace "DC_SHA1" variable with a "define"Ævar Arnfjörð Bjarmason
Address the root cause of technical debt we've been carrying since sha1collisiondetection was made the default in [1]. In a preceding commit we narrowly fixed a bug where the "DC_SHA1" variable would be unset (in combination with "NO_APPLE_COMMON_CRYPTO=" on OSX), even though we had the sha1collisiondetection library enabled. But the only reason we needed to have such a user-exposed knob went away with [1], and it's been doing nothing useful since then. We don't care if you define DC_SHA1=*, we only care that you don't ask for any other SHA-1 implementation. If it turns out that you didn't, we'll use sha1collisiondetection, whether you had "DC_SHA1" set or not. As a result of this being confusing we had e.g. [2] for cmake and the recent [3] for ci/ setting "DC_SHA1" explicitly, even though this was always a NOOP. A much simpler way to do this is to stop having the Makefile and CMakeLists.txt set "DC_SHA1" to be picked up by the, let's instead add a trivial "test-tool sha1-is-sha1dc". It returns zero if we're using sha1collisiondetection, non-zero otherwise. 1. e6b07da2780 (Makefile: make DC_SHA1 the default, 2017-03-17) 2. c4b2f41b5f5 (cmake: support for testing git with ctest, 2020-06-26) 3. 1ad5c3df35a (ci: use DC_SHA1=YesPlease on osx-clang job for CI, 2022-10-20) Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Taylor Blau <>
2022-10-27Merge branch 'js/cmake-updates'Junio C Hamano
Update to build procedure with VS using CMake/CTest. * js/cmake-updates: cmake: increase time-out for a long-running test cmake: avoid editing t/ add -p: avoid ambiguous signed/unsigned comparison cmake: copy the merge tools for testing cmake: make it easier to diagnose regressions in CTest runs
2022-10-19cmake: increase time-out for a long-running testJohannes Schindelin
As suggested in, t7112 can run for well over one hour, which seems to be the default maximum run time at least when running CTest-based tests in Visual Studio. Let's increase the time-out as a stop gap to unblock developers wishing to run Git's test suite in Visual Studio. Note: The actual run time is highly dependent on the circumstances. For example, in Git's CI runs, the Windows-based tests typically take a bit over 5 minutes to run. CI runs have the added benefit that Windows Defender (the common anti-malware scanner on Windows) is turned off, something many developers are not at liberty to do on their work stations. When Defender is turned on, even on this developer's high-end Ryzen system, t7112 takes over 15 minutes to run. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2022-10-19cmake: avoid editing t/test-lib.shJohannes Schindelin
In 7f5397a07c6c (cmake: support for testing git when building out of the source tree, 2020-06-26), we implemented support for running Git's test scripts even after building Git in a different directory than the source directory. The way we did this was to edit the file `t/` to override `GIT_BUILD_DIR` to point somewhere else than the parent of the `t/` directory. This is unideal because it always leaves a tracked file marked as modified, and it is all too easy to commit that change by mistake. Let's change the strategy by teaching `t/` to detect the presence of a file called `GIT-BUILD-DIR` in the source directory. If it exists, the contents are interpreted as the location to the _actual_ build directory. We then write this file as part of the CTest definition. To support building Git via a regular `make` invocation after building it using CMake, we ensure that the `GIT-BUILD-DIR` file is deleted (for convenience, this is done as part of the Makefile rule that is already run with every `make` invocation to ensure that `GIT-BUILD-OPTIONS` is up to date). Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2022-10-19cmake: copy the merge tools for testingJohannes Schindelin
Even when running the tests via CTest, t7609 and t7610 rely on more than only a few mergetools to be copied to the build directory. Let's make it so. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2022-10-19cmake: make it easier to diagnose regressions in CTest runsJohannes Schindelin
When a test script fails in Git's test suite, the usual course of action is to re-run it using options to increase the verbosity of the output, e.g. `-v` and `-x`. Like in Git's CI runs, when running the tests in Visual Studio via the CTest route, it is cumbersome or at least requires a very unintuitive approach to pass options to the test scripts: the CMakeLists.txt file would have to be modified, passing the desired options to _all_ test scripts, and then the CMake Cache would have to be reconfigured before running the test in question individually. Unintuitive at best, and opposite to the niceties IDE users expect. So let's just pass those options by default: This will not clutter any output window but the log that is written to a log file will have information necessary to figure out test failures. While at it, also imitate what the Windows jobs in Git's CI runs do to accelerate running the test scripts: pass the `--no-bin-wrappers` and `--no-chain-lint` options. This makes the test runs noticeably faster because the `bin-wrappers/` scripts as well as the `chain-lint` code make heavy use of POSIX shell scripting, which is really, really slow on Windows due to the need to emulate POSIX behavior via the MSYS2 runtime. In a test by Eric Sunshine, it added two minutes (!) just to perform the chain-lint task. The idea of adding a CMake config option (á la `GIT_TEST_OPTS`) was considered during the development of this patch, but then dropped: such a setting is global, across _all_ tests, where e.g. `--run=...` would not make sense. Users wishing to override these new defaults are better advised running the test script manually, in a Git Bash, with full control over the command line. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2022-10-17Merge branch 'ed/fsmonitor-on-networked-macos'Junio C Hamano
By default, use of fsmonitor on a repository on networked filesystem is disabled. Add knobs to make it workable on macOS. * ed/fsmonitor-on-networked-macos: fsmonitor: fix leak of warning message fsmonitor: add documentation for allowRemote and socketDir options fsmonitor: check for compatability before communicating with fsmonitor fsmonitor: deal with synthetic firmlinks on macOS fsmonitor: avoid socket location check if using hook fsmonitor: relocate socket file if .git directory is remote fsmonitor: refactor filesystem checks to common interface
2022-10-05fsmonitor: relocate socket file if .git directory is remoteEric DeCosta
If the .git directory is on a remote filesystem, create the socket file in 'fsmonitor.socketDir' if it is defined, else create it in $HOME. Signed-off-by: Eric DeCosta <> Signed-off-by: Junio C Hamano <>
2022-10-05fsmonitor: refactor filesystem checks to common interfaceEric DeCosta
Provide a common interface for getting basic filesystem information including filesystem type and whether the filesystem is remote. Refactor existing code for getting basic filesystem info and detecting remote file systems to the new interface. Refactor filesystem checks to leverage new interface. For macOS, error-out if the Unix Domain socket (UDS) file is on a remote filesystem. Signed-off-by: Eric DeCosta <> Signed-off-by: Junio C Hamano <>
2022-09-19Merge branch 'vd/scalar-to-main'Junio C Hamano
Hoist the remainder of "scalar" out of contrib/ to the main part of the codebase. * vd/scalar-to-main: Documentation/technical: include Scalar technical doc t/perf: add 'GIT_PERF_USE_SCALAR' run option t/perf: add Scalar performance tests scalar-clone: add test coverage scalar: add to 'git help -a' command list scalar: implement the `help` subcommand git help: special-case `scalar` scalar: include in standard Git build & installation scalar: fix command documentation section header
2022-09-02scalar: include in standard Git build & installationVictoria Dye
Move 'scalar' out of 'contrib/' and into the root of the Git tree. The goal of this change is to build 'scalar' as part of the standard Git build & install processes. This patch includes both the physical move of Scalar's files out of 'contrib/' ('scalar.c', 'scalar.txt', and ''), and the changes to the build definitions in 'Makefile' and 'CMakelists.txt' to accommodate the new program. At a high level, Scalar is built so that: - there is a 'scalar-objs' target (similar to those created in 029bac01a8 (Makefile: add {program,xdiff,test,git,fuzz}-objs & objects targets, 2021-02-23)) for debugging purposes. - it appears in the root of the install directory (rather than the gitexecdir). - it is included in the 'bin-wrappers/' directory for use in tests. - it receives a platform-specific executable suffix (e.g., '.exe'), if applicable. - 'scalar.txt' is installed as 'man1' documentation. - the 'clean' target removes the 'scalar' executable. Additionally, update the root level '.gitignore' file to ignore the Scalar executable. Signed-off-by: Victoria Dye <> Signed-off-by: Junio C Hamano <>
2022-09-01test-lib: replace chainlint.sed with chainlint.plEric Sunshine
By automatically invoking chainlint.sed upon each test it runs, `test_run_` in ensures that broken &&-chains will be detected early as tests are modified or new are tests created since it is typical to run a test script manually (i.e. `./`) during test development. Now that the implementation of is complete, modify to invoke it automatically instead of chainlint.sed each time a test script is run. This change reduces the number of "linter" invocations from 26800+ (once per test run) down to 1050+ (once per test script), however, a subsequent change will drop the number of invocations to 1 per `make test`, thus fully realizing the benefit of the new linter. Note that the "magic exit code 117" &&-chain checker added by bb79af9d09 (t/test-lib: introduce --chain-lint option, 2015-03-20) which is built into t/ is retained since it has near zero-cost and (theoretically) may catch a broken &&-chain not caught by Signed-off-by: Eric Sunshine <> Signed-off-by: Junio C Hamano <>
2022-07-27cmake: support local installations of gitCarlo Marcelo Arenas Belón
At least in systems where the user is local and not an administrator git will install in a subdirectory of %APPDATALOCAL%, so it makes sense to also look there for the shell needed by the cmake integration with Visual Studio. Signed-off-by: Carlo Marcelo Arenas Belón <> Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2022-06-10Merge branch 'jh/builtin-fsmonitor-part3'Junio C Hamano
More fsmonitor--daemon. * jh/builtin-fsmonitor-part3: (30 commits) t7527: improve implicit shutdown testing in fsmonitor--daemon fsmonitor--daemon: allow --super-prefix argument t7527: test Unicode NFC/NFD handling on MacOS t/lib-unicode-nfc-nfd: helper prereqs for testing unicode nfc/nfd t/helper/hexdump: add helper to print hexdump of stdin fsmonitor: on macOS also emit NFC spelling for NFD pathname t7527: test FSMonitor on case insensitive+preserving file system fsmonitor: never set CE_FSMONITOR_VALID on submodules t/perf/p7527: add perf test for builtin FSMonitor t7527: FSMonitor tests for directory moves fsmonitor: optimize processing of directory events fsm-listen-darwin: shutdown daemon if worktree root is moved/renamed fsm-health-win32: force shutdown daemon if worktree root moves fsm-health-win32: add polling framework to monitor daemon health fsmonitor--daemon: stub in health thread fsmonitor--daemon: rename listener thread related variables fsmonitor--daemon: prepare for adding health thread fsmonitor--daemon: cd out of worktree root fsm-listen-darwin: ignore FSEvents caused by xattr changes on macOS unpack-trees: initialize fsmonitor_has_run_once in o->result ...
2022-05-26fsmonitor--daemon: stub in health threadJeff Hostetler
Create another thread to watch over the daemon process and automatically shut it down if necessary. This commit creates the basic framework for a "health" thread to monitor the daemon and/or the file system. Later commits will add platform-specific code to do the actual work. The "health" thread is intended to monitor conditions that would be difficult to track inside the IPC thread pool and/or the file system listener threads. For example, when there are file system events outside of the watched worktree root or if we want to have an idle-timeout auto-shutdown feature. This commit creates the health thread itself, defines the thread-proc and sets up the thread's event loop. It integrates this new thread into the existing IPC and Listener thread models. This commit defines the API to the platform-specific code where all of the monitoring will actually happen. The platform-specific code for MacOS is just stubs. Meaning that the health thread will immediately exit on MacOS, but that is OK and expected. Future work can define MacOS-specific monitoring. The platform-specific code for Windows sets up enough of the WaitForMultipleObjects() machinery to watch for system and/or custom events. Currently, the set of wait handles only includes our custom shutdown event (sent from our other theads). Later commits in this series will extend the set of wait handles to monitor other conditions. Signed-off-by: Jeff Hostetler <> Signed-off-by: Junio C Hamano <>
2022-05-26fsmonitor-settings: stub in macOS-specific incompatibility checkingJeff Hostetler
Signed-off-by: Jeff Hostetler <> Signed-off-by: Junio C Hamano <>
2022-05-26fsmonitor-settings: stub in Win32-specific incompatibility checkingJeff Hostetler
Extend generic incompatibility checkout with platform-specific mechanism. Stub in Win32 version. In the existing fsmonitor-settings code we have a way to mark types of repos as incompatible with fsmonitor (whether via the hook and IPC APIs). For example, we do this for bare repos, since there are no files to watch. Extend this exclusion mechanism for platform-specific reasons. This commit just creates the framework and adds a stub for Win32. Signed-off-by: Jeff Hostetler <> Signed-off-by: Junio C Hamano <>
2022-05-24cmake: remove (_)UNICODE def on Windows in CMakeLists.txtYuyi Wang
`UNICODE` and `_UNICODE` are not required when building git on Windows. Actually, they should not be predefined at all. There're 2 evidences that `(_)UNICODE` is supposed to be nonexist: compat/win32/trace2_win32_process_info.c:83: It uses jw_array_string which accepts pe32.szExeFile as const char*. t/helper/test-drop-caches.c:16: Calling to GetCurrentDirectory with Buffer as char*. The autotools build system never defines `UNICODE` and `_UNICODE` and builds on Windows well. Signed-off-by: Yuyi Wang <> Acked-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2022-05-24cmake: add pcre2 supportYuyi Wang
Fix one of the TODOs listed in the CMakeLists.txt by adding support for building with pcre2. As pcre2 doesn't provide cmake find module, we find it with pkgconf. This patch also works with vcpkg on Windows, with pkgconf and pcre2 installed. Pkgconf and pcre2 is detected automatically just like curl, expat and iconv. The output of CMake indicates whether pcre2 is found. Signed-off-by: Yuyi Wang <> Signed-off-by: Junio C Hamano <>
2022-05-24cmake: fix CMakeLists.txt on LinuxYuyi Wang
CMakeLists.txt didn't follow the grammar of `set`, and it will fail when setting `USE_VCPKG` off on non-Windows platforms. When the platform is Linux, the Makefile adds `compat/linux/procinfo.o` to `COMPAT_OBJS`, but the CMakeLists.txt didn't add `compat/linux/procinfo.c` to `compat_SOURCES`. It would cause linkage error. Signed-off-by: Yuyi Wang <> Signed-off-by: Junio C Hamano <>
2022-04-04Merge branch 'jh/builtin-fsmonitor-part2'Junio C Hamano
Built-in fsmonitor (part 2). * jh/builtin-fsmonitor-part2: (30 commits) t7527: test status with untracked-cache and fsmonitor--daemon fsmonitor: force update index after large responses fsmonitor--daemon: use a cookie file to sync with file system fsmonitor--daemon: periodically truncate list of modified files t/perf/p7519: add fsmonitor--daemon test cases t/perf/p7519: speed up test on Windows t/perf/p7519: fix coding style t/helper/test-chmtime: skip directories on Windows t/perf: avoid copying builtin fsmonitor files into test repo t7527: create test for fsmonitor--daemon t/helper/fsmonitor-client: create IPC client to talk to FSMonitor Daemon help: include fsmonitor--daemon feature flag in version info fsmonitor--daemon: implement handle_client callback compat/fsmonitor/fsm-listen-darwin: implement FSEvent listener on MacOS compat/fsmonitor/fsm-listen-darwin: add MacOS header files for FSEvent compat/fsmonitor/fsm-listen-win32: implement FSMonitor backend on Windows fsmonitor--daemon: create token-based changed path cache fsmonitor--daemon: define token-ids fsmonitor--daemon: add pathname classification fsmonitor--daemon: implement 'start' command ...
2022-03-25compat/fsmonitor/fsm-listen-darwin: stub in backend for DarwinJeff Hostetler
Stub in empty implementation of fsmonitor--daemon backend for Darwin (aka MacOS). Signed-off-by: Jeff Hostetler <> Signed-off-by: Junio C Hamano <>
2022-03-25compat/fsmonitor/fsm-listen-win32: stub in backend for WindowsJeff Hostetler
Stub in empty filesystem listener backend for fsmonitor--daemon on Windows. Signed-off-by: Jeff Hostetler <> Signed-off-by: Junio C Hamano <>
2022-03-10core.fsyncmethod: add writeout-only modeNeeraj Singh
This commit introduces the `core.fsyncMethod` configuration knob, which can currently be set to `fsync` or `writeout-only`. The new writeout-only mode attempts to tell the operating system to flush its in-memory page cache to the storage hardware without issuing a CACHE_FLUSH command to the storage controller. Writeout-only fsync is significantly faster than a vanilla fsync on common hardware, since data is written to a disk-side cache rather than all the way to a durable medium. Later changes in this patch series will take advantage of this primitive to implement batching of hardware flushes. When git_fsync is called with FSYNC_WRITEOUT_ONLY, it may fail and the caller is expected to do an ordinary fsync as needed. On Apple platforms, the fsync system call does not issue a CACHE_FLUSH directive to the storage controller. This change updates fsync to do fcntl(F_FULLFSYNC) to make fsync actually durable. We maintain parity with existing behavior on Apple platforms by setting the default value of the new core.fsyncMethod option. Signed-off-by: Neeraj Singh <> Signed-off-by: Junio C Hamano <>
2022-01-17wrapper: add a helper to generate numbers from a CSPRNGbrian m. carlson
There are many situations in which having access to a cryptographically secure pseudorandom number generator (CSPRNG) is helpful. In the future, we'll encounter one of these when dealing with temporary files. To make this possible, let's add a function which reads from a system CSPRNG and returns some bytes. We know that all systems will have such an interface. A CSPRNG is required for a secure TLS or SSH implementation and a Git implementation which provided neither would be of little practical use. In addition, POSIX is set to standardize getentropy(2) in the next version, so in the (potentially distant) future we can rely on that. For systems which lack one of the other interfaces, we provide the ability to use OpenSSL's CSPRNG. OpenSSL is highly portable and functions on practically every known OS, and we know it will have access to some source of cryptographically secure randomness. We also provide support for the arc4random in libbsd for folks who would prefer to use that. Because this is a security sensitive interface, we take some precautions. We either succeed by filling the buffer completely as we requested, or we fail. We don't return partial data because the caller will almost never find that to be a useful behavior. Specify a makefile knob which users can use to specify one or more suitable CSPRNGs, and turn the multiple string options into a set of defines, since we cannot match on strings in the preprocessor. We allow multiple options to make the job of handling this in autoconf easier. The order of options is important here. On systems with arc4random, which is most of the BSDs, we use that, since, except on MirBSD and macOS, it uses ChaCha20, which is extremely fast, and sits entirely in userspace, avoiding a system call. We then prefer getrandom over getentropy, because the former has been available longer on Linux, and then OpenSSL. Finally, if none of those are available, we use /dev/urandom, because most Unix-like operating systems provide that API. We prefer options that don't involve device files when possible because those work in some restricted environments where device files may not be available. Set the configuration variables appropriately for Linux and the BSDs, including macOS, as well as Windows and NonStop. We specifically only consider versions which receive publicly available security support here. For the same reason, we don't specify getrandom(2) on Linux, because CentOS 7 doesn't support it in glibc (although its kernel does) and we don't want to resort to making syscalls. Finally, add a test helper to allow this to be tested by hand and in tests. We don't add any tests, since invoking the CSPRNG is not likely to produce interesting, reproducible results. Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2021-12-15Merge branch 'hn/reftable'Junio C Hamano
The "reftable" backend for the refs API, without integrating into the refs subsystem, has been added. * hn/reftable: Add "test-tool dump-reftable" command. reftable: add dump utility reftable: implement stack, a mutable database of reftable files. reftable: implement refname validation reftable: add merged table view reftable: add a heap-based priority queue for reftable records reftable: reftable file level tests reftable: read reftable files reftable: generic interface to tables reftable: write reftable files reftable: a generic binary tree implementation reftable: reading/writing blocks Provide zlib's uncompress2 from compat/zlib-compat.c reftable: (de)serialization for the polymorphic record type. reftable: add blocksource, an abstraction for random access reads reftable: utility functions reftable: add error related functionality reftable: add LICENSE hash.h: provide constants for the hash IDs
2021-12-10Merge branch 'bc/require-c99'Junio C Hamano
Weather balloon to break people with compilers that do not support C99. * bc/require-c99: git-compat-util: add a test balloon for C99 support
2021-12-01git-compat-util: add a test balloon for C99 supportbrian m. carlson
The C99 standard was released in January 1999, now 22 years ago. It provides a variety of useful features, including variadic arguments for macros, declarations after statements, designated initializers, and a wide variety of other useful features, many of which we already use. We'd like to take advantage of these features, but we want to be cautious. As far as we know, all major compilers now support C99 or a later C standard, such as C11 or C17. POSIX has required C99 support as a requirement for the 2001 revision, so we can safely assume any POSIX system which we are interested in supporting has C99. Even MSVC, long a holdout against modern C, now supports both C11 and C17 with an appropriate update. Moreover, even if people are using an older version of MSVC on these systems, they will generally need some implementation of the standard Unix utilities for the testsuite, and GNU coreutils, the most common option, has required C99 since 2009. Therefore, we can safely assume that a suitable version of GCC or clang is available to users even if their version of MSVC is not sufficiently capable. Let's add a test balloon to git-compat-util.h to see if anyone is using an older compiler. We'll add a comment telling people how to enable this functionality on GCC and Clang, even though modern versions of both will automatically do the right thing, and ask people still experiencing a problem to report that to us on the list. Note that C89 compilers don't provide the __STDC_VERSION__ macro, so we use a well-known hack of using "- 0". On compilers with this macro, it doesn't change the value, and on C89 compilers, the macro will be replaced with nothing, and our value will be 0. For sparse, we explicitly request the gnu99 style because we've traditionally taken advantage of some GCC- and clang-specific extensions when available and we'd like to retain the ability to do that. sparse also defaults to C89 without it, so things will fail for us if we don't. Update the cmake configuration to require C11 for MSVC. We do this because this will make MSVC to use C11, since it does not explicitly support C99. We do this with a compiler options because setting the C_STANDARD option does not work in our CI on MSVC and at the moment, we don't want to require C11 for Unix compilers. In the Makefile, don't set any compiler flags for the compiler itself, since on some systems, such as FreeBSD, we actually need C11, and asking for C99 causes things to fail to compile. The error message should make it obvious what's going wrong and allow a user to set the appropriate option when building in the event they're using a Unix compiler that doesn't support it by default. Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2021-10-21git-sh-setup: remove "sane_grep", it's not needed anymoreÆvar Arnfjörð Bjarmason
Remove the sane_grep() shell function in git-sh-setup. The two reasons for why it existed don't apply anymore: 1. It was added due to GNU grep supporting GREP_OPTIONS. See e1622bfcbad (Protect scripted Porcelains from GREP_OPTIONS insanity, 2009-11-23). Newer versions of GNU grep ignore that, but even on older versions its existence won't matter, none of these sane_grep() uses care about grep's output, they're merely using it to check if a string exists in a file or stream. We also don't care about the "LC_ALL=C" that "sane_grep" was using, these greps for fixed or ASCII strings will behave the same under any locale. 2. The SANE_TEXT_GREP added in 71b401032b9 (sane_grep: pass "-a" if grep accepts it, 2016-03-08) isn't needed either, none of these grep uses deal with binary data. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2021-10-08reftable: utility functionsHan-Wen Nienhuys
This commit provides basic utility classes for the reftable library. Signed-off-by: Han-Wen Nienhuys <> Helped-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2021-09-27hook-list.h: add a generated list of hooks, like config-list.hÆvar Arnfjörð Bjarmason
Make githooks(5) the source of truth for what hooks git supports, and punt out early on hooks we don't know about in find_hook(). This ensures that the documentation and the C code's idea about existing hooks doesn't diverge. We still have Perl and Python code running its own hooks, but that'll be addressed by Emily Shaffer's upcoming "git hook run" command. This resolves a long-standing TODO item in bugreport.c of there being no centralized listing of hooks, and fixes a bug with the bugreport listing only knowing about 1/4 of the p4 hooks. It didn't know about the recent "reference-transaction" hook either. We could make the find_hook() function die() or BUG() out if the new known_hook() returned 0, but let's make it return NULL just as it does when it can't find a hook of a known type. Making it die() is overly anal, and unlikely to be what we need in catching stupid typos in the name of some new hook hardcoded in git.git's sources. By making this be tolerant of unknown hook names, changes in a later series to make "git hook run" run arbitrary user-configured hook names will be easier to implement. I have not been able to directly test the CMake change being made here. Since 4c2c38e800 (ci: modification of main.yml to use cmake for vs-build job, 2020-06-26) some of the Windows CI has a hard dependency on CMake, this change works there, and is to my eyes an obviously correct use of a pattern established in previous CMake changes, namely: - 061c2240b1 (Introduce CMake support for configuring Git, 2020-06-12) - 709df95b78 (help: move list_config_help to builtin/help, 2020-04-16) - 976aaedca0 (msvc: add a Makefile target to pre-generate the Visual Studio solution, 2019-07-29) The LC_ALL=C is needed because at least in my locale the dash ("-") is ignored for the purposes of sorting, which results in a different order. I'm not aware of anything in git that has a hard dependency on the order, but e.g. the bugreport output would end up using whatever locale was in effect when git was compiled. Signed-off-by: Ævar Arnfjörð Bjarmason <> Helped-by: René Scharfe <> Signed-off-by: Junio C Hamano <>
2021-07-17Merge branch 'js/gfw-system-config-loc-fix'Junio C Hamano
Update the location of system-side configuration file on Windows. * js/gfw-system-config-loc-fix: config: normalize the path of the system gitconfig cmake(windows): set correct path to the system Git config mingw: move Git for Windows' system config where users expect it
2021-07-13Merge branch 'mr/cmake'Junio C Hamano
CMake update. * mr/cmake: cmake: add warning for ignored MSGFMT_EXE cmake: create compile_commands.json by default cmake: add knob to disable vcpkg
2021-06-29cmake(windows): set correct path to the system Git configDennis Ameling
Currently, when Git for Windows is built with CMake, the system Git config is expected in a different location than when building via `make`: the former expects it to be in `<runtime-prefix>/mingw64/etc/gitconfig`, the latter in `<runtime-prefix>/etc/gitconfig`. Because of this, things like `git clone` do not work correctly (because cURL is no longer able to find its certificate bundle that it needs to validate HTTPS certificates). See the full bug report and discussion here: This commit aligns the CMake-based build by mimicking what is already done in `config.mak.uname`. This closes Signed-off-by: Dennis Ameling <> Signed-off-by: Junio C Hamano <>
2021-06-11cmake: add warning for ignored MSGFMT_EXEMatthew Rogers
It does not make sense to attempt to set MSGFMT_EXE when NO_GETTEXT is configured, as such add a check for NO_GETTEXT before attempting to set it. Suggested-by: Johannes Schindelin <> Signed-off-by: Matthew Rogers <> Acked-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2021-06-11cmake: create compile_commands.json by defaultMatthew Rogers
Some users have expressed interest in a more "batteries included" way of building via CMake[1], and a big part of that is providing easier access to tooling external tools. A straightforward way to accomplish this is to make it as simple as possible is to enable the generation of the compile_commands.json file, which is supported by many tools such as: clang-tidy, clang-format, sourcetrail, etc. This does come with a small run-time overhead during the configuration step (~6 seconds on my machine): Time to configure with CMAKE_EXPORT_COMPILE_COMMANDS=TRUE real 1m9.840s user 0m0.031s sys 0m0.031s Time to configure with CMAKE_EXPORT_COMPILE_COMMANDS=FALSE real 1m3.195s user 0m0.015s sys 0m0.015s This seems like a small enough price to pay to make the project more accessible to newer users. Additionally there are other large projects like llvm [2] which has had this enabled by default for >6 years at the time of this writing, and no real negative consequences that I can find with my search-skills. NOTE: That the compile_commands.json is currently produced only when using the Ninja and Makefile generators. See The CMake documentation[3] for more info. 1: 2: 3: Signed-off-by: Matthew Rogers <> Acked-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2021-06-11cmake: add knob to disable vcpkgMatthew Rogers
When building on windows users have the option to use vcpkg to provide the dependencies needed to compile. Previously, this was used only when using the Visual Studio generator which was not ideal because: - Not all users who want to use vcpkg use the Visual Studio generators. - Some versions of Visual Studio 2019 moved away from using the VS 2019 generator by default, making it impossible for Visual Studio to configure the project in the likely event that it couldn't find the dependencies. - Inexperienced users of CMake are very likely to get tripped up by the errors caused by a lack of vcpkg, making the above bullet point both annoying and hard to debug. As such, let's make using vcpkg the default on windows. Users who want to avoid using vcpkg can disable it by passing -DNO_VCPKG=TRUE. Signed-off-by: Matthew Rogers <> Acked-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2021-05-22Merge branch 'jh/simple-ipc-sans-pthread'Junio C Hamano
The "simple-ipc" did not compile without pthreads support, but the build procedure was not properly account for it. * jh/simple-ipc-sans-pthread: simple-ipc: correct ifdefs when NO_PTHREADS is defined
2021-05-20simple-ipc: correct ifdefs when NO_PTHREADS is definedJeff Hostetler
Simple IPC always requires threads (in addition to various platform-specific IPC support). Fix the ifdefs in the Makefile to define SUPPORTS_SIMPLE_IPC when appropriate. Previously, the Unix version of the code would only verify that Unix domain sockets were available. This problem was reported here: Reported-by: Randall S. Becker <> Helped-by: Jeff King <> Signed-off-by: Jeff Hostetler <> Signed-off-by: Junio C Hamano <>
2021-04-07Merge branch 'js/cmake-vsbuild'Junio C Hamano
CMake update for vsbuild. * js/cmake-vsbuild: cmake(install): include vcpkg dlls cmake: add a preparatory work-around to accommodate `vcpkg` cmake(install): fix double .exe suffixes cmake: support SKIP_DASHED_BUILT_INS
2021-04-02Merge branch 'jh/simple-ipc'Junio C Hamano
A simple IPC interface gets introduced to build services like fsmonitor on top. * jh/simple-ipc: t0052: add simple-ipc tests and t/helper/test-simple-ipc tool simple-ipc: add Unix domain socket implementation unix-stream-server: create unix domain socket under lock unix-socket: disallow chdir() when creating unix domain sockets unix-socket: add backlog size option to unix_stream_listen() unix-socket: eliminate static unix_stream_socket() helper function simple-ipc: add win32 implementation simple-ipc: design documentation for new IPC mechanism pkt-line: add options argument to read_packetized_to_strbuf() pkt-line: add PACKET_READ_GENTLE_ON_READ_ERROR option pkt-line: do not issue flush packets in write_packetized_*() pkt-line: eliminate the need for static buffer in packet_write_gently()
2021-03-29cmake(install): include vcpkg dllsDennis Ameling
Our CMake configuration generates not only build definitions, but also install definitions: After building Git using `msbuild git.sln`, the built artifacts can be installed via `msbuild INSTALL.vcxproj`. To specify _where_ the files should be installed, the `-DCMAKE_INSTALL_PREFIX=<path>` option can be used when running CMake. However, this process would really only install the files that were just built. On Windows, we need more than that: We also need the `.dll` files of the dependencies (such as libcurl). The `vcpkg` ecosystem, which we use to obtain those dependencies, can be asked to install said `.dll` files really easily, so let's do that. This requires more than just the built `vcpkg` artifacts in the CI build definition; We now clone the `vcpkg` repository so that the relevant CMake scripts are available, in particular the ones related to defining the toolchain. Signed-off-by: Dennis Ameling <> Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2021-03-29cmake: add a preparatory work-around to accommodate `vcpkg`Johannes Schindelin
We are about to add support for installing the `.dll` files of Git's dependencies (such as libcurl) in the CMake configuration. The `vcpkg` ecosystem from which we get said dependencies makes that relatively easy: simply turn on `X_VCPKG_APPLOCAL_DEPS_INSTALL`. However, current `vcpkg` introduces a limitation if one does that: While it is totally cool with CMake to specify multiple targets within one invocation of `install(TARGETS ...) (at least according to, `vcpkg`'s parser insists on a single target per `install(TARGETS ...)` invocation. Well, that's easily accomplished: Let's feed the targets individually to the `install(TARGETS ...)` function in a `foreach()` look. This also has the advantage that we do not have to manually cull off the two entries from the `${PROGRAMS_BUILT}` array before scheduling the remainder to be installed into `libexec/git-core`. Instead, we iterate through the array and decide for each entry where it wants to go. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2021-03-28cmake(install): fix double .exe suffixesDennis Ameling
By mistake, the `.exe` extension is appended _twice_ when installing the dashed executables into `libexec/git-core/` on Windows (the extension is already appended when adding items to the `git_links` list in the `#Creating hardlinks` section). Signed-off-by: Dennis Ameling <> Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2021-03-28cmake: support SKIP_DASHED_BUILT_INSJohannes Schindelin
Just like the Makefile-based build learned to skip hard-linking the dashed built-ins in 179227d6e21 (Optionally skip linking/copying the built-ins, 2020-09-21), this patch teaches the CMake-based build the same trick. Note: In contrast to the Makefile-based process, the built-ins would only be linked during installation, not already when Git is built. Therefore, the CMake-based build that we use in our CI builds _already_ does not link those built-ins (because the files are not installed anywhere, they are used to run the test suite in-place). Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2021-03-22simple-ipc: add Unix domain socket implementationJeff Hostetler
Create Unix domain socket based implementation of "simple-ipc". A set of `ipc_client` routines implement a client library to connect to an `ipc_server` over a Unix domain socket, send a simple request, and receive a single response. Clients use blocking IO on the socket. A set of `ipc_server` routines implement a thread pool to listen for and concurrently service client connections. The server creates a new Unix domain socket at a known location. If a socket already exists with that name, the server tries to determine if another server is already listening on the socket or if the socket is dead. If socket is busy, the server exits with an error rather than stealing the socket. If the socket is dead, the server creates a new one and starts up. If while running, the server detects that its socket has been stolen by another server, it automatically exits. Signed-off-by: Jeff Hostetler <> Signed-off-by: Junio C Hamano <>
2021-03-15unix-stream-server: create unix domain socket under lockJeff Hostetler
Create a wrapper class for `unix_stream_listen()` that uses a ".lock" lockfile to create the unix domain socket in a race-free manner. Unix domain sockets have a fundamental problem on Unix systems because they persist in the filesystem until they are deleted. This is independent of whether a server is actually listening for connections. Well-behaved servers are expected to delete the socket when they shutdown. A new server cannot easily tell if a found socket is attached to an active server or is leftover cruft from a dead server. The traditional solution used by `unix_stream_listen()` is to force delete the socket pathname and then create a new socket. This solves the latter (cruft) problem, but in the case of the former, it orphans the existing server (by stealing the pathname associated with the socket it is listening on). We cannot directly use a .lock lockfile to create the socket because the socket is created by `bind(2)` rather than the `open(2)` mechanism used by `tempfile.c`. As an alternative, we hold a plain lockfile ("<path>.lock") as a mutual exclusion device. Under the lock, we test if an existing socket ("<path>") is has an active server. If not, we create a new socket and begin listening. Then we use "rollback" to delete the lockfile in all cases. This wrapper code conceptually exists at a higher-level than the core unix_stream_connect() and unix_stream_listen() routines that it consumes. It is isolated in a wrapper class for clarity. Signed-off-by: Jeff Hostetler <> Signed-off-by: Junio C Hamano <>
2021-03-15simple-ipc: add win32 implementationJeff Hostetler
Create Windows implementation of "simple-ipc" using named pipes. Signed-off-by: Jeff Hostetler <> Signed-off-by: Junio C Hamano <>
2021-01-24Remove support for v1 of the PCRE libraryÆvar Arnfjörð Bjarmason
Remove support for using version 1 of the PCRE library. Its use has been discouraged by upstream for a long time, and it's in a bugfix-only state. Anyone who was relying on v1 in particular got a nudge to move to v2 in e6c531b808 (Makefile: make USE_LIBPCRE=YesPlease mean v2, not v1, 2018-03-11), which was first released as part of v2.18.0. With this the LIBPCRE2 test prerequisites is redundant to PCRE. But I'm keeping it for self-documentation purposes, and to avoid conflict with other in-flight PCRE patches. I'm also not changing all of our own "pcre2" names to "pcre", i.e. the inverse of 6d4b5747f0 (grep: change internal *pcre* variable & function names to be *pcre1*, 2017-05-25). I don't see the point, and it makes the history/blame harder to read. Maybe if there's ever a PCRE v3... Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2020-12-04cmake: determine list of extra built-ins dynamicallyJohannes Schindelin
In 0a21d0e08902 (Makefile: mark git-maintenance as a builtin, 2020-12-01), we marked git-maintenance as a builtin in the Makefile, but forgot to do the same in `CMakeLists.txt`. Rather than always play catch-up and adjust `git_builtin_extra` manually, use the `BUILT_INS` definitions in the Makefile as authoritative source and generate `git_builtin_extra` dynamically. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>