summaryrefslogtreecommitdiff
path: root/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2022-01-10Merge branch 'ab/makefile-hook-list-dependency-fix'Libravatar Junio C Hamano1-2/+2
Fix dependency rules to generate hook-list.h header file. * ab/makefile-hook-list-dependency-fix: Makefile: correct the dependency graph of hook-list.h
2022-01-10Merge branch 'ab/makefile-pager-env-is-used-only-by-pager.c'Libravatar Junio C Hamano1-5/+6
* ab/makefile-pager-env-is-used-only-by-pager.c: Makefile: move -DPAGER_ENV from BASIC_CFLAGS to EXTRA_CPPFLAGS
2022-01-10Merge branch 'ab/makefile-msgfmt-wo-stats'Libravatar Junio C Hamano1-1/+1
Make the recipe that runs msgfmt less noisy. * ab/makefile-msgfmt-wo-stats: Makefile: don't invoke msgfmt with --statistics
2021-12-25Makefile: don't invoke msgfmt with --statisticsLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Remove the --statistics flag that I added in 5e9637c6297 (i18n: add infrastructure for translating Git with gettext, 2011-11-18). Our Makefile output is good about reducing verbosity by default, except in this case: $ rm -rf po/build/locale/e*; time make -j $(nproc) all SUBDIR templates MKDIR -p po/build/locale/el/LC_MESSAGES MSGFMT po/build/locale/el/LC_MESSAGES/git.mo MKDIR -p po/build/locale/es/LC_MESSAGES MSGFMT po/build/locale/es/LC_MESSAGES/git.mo 1038 translated messages, 3325 untranslated messages. 5230 translated messages. I didn't have any good reason for using --statistics at the time other than ad-hoc eyeballing of the output. We don't need to spew out exactly how many messages we've got translated every time. Now we'll instead emit: $ rm -rf po/build/locale/e*; time make -j $(nproc) all SUBDIR templates MKDIR -p po/build/locale/el/LC_MESSAGES MSGFMT po/build/locale/el/LC_MESSAGES/git.mo MKDIR -p po/build/locale/es/LC_MESSAGES MSGFMT po/build/locale/es/LC_MESSAGES/git.mo Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-25Makefile: move -DPAGER_ENV from BASIC_CFLAGS to EXTRA_CPPFLAGSLibravatar Ævar Arnfjörð Bjarmason1-5/+6
Remove -DPAGER_ENV from the BASIC_CFLAGS and instead have it passed via the EXTRA_CPPFLAGS passed when compiling pager.c. This doesn't change anything except to make it clear that only pager.c needs this, as it's the only user of this define. See 995bc22d7f8 (pager: move pager-specific setup into the build, 2016-08-04) for the commit that originally added this. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-25Makefile: correct the dependency graph of hook-list.hLibravatar Ævar Arnfjörð Bjarmason1-2/+2
Fix an issue in my cfe853e66be (hook-list.h: add a generated list of hooks, like config-list.h, 2021-09-26), the builtin/help.c was inadvertently made to depend on hook-list.h, but it's used by builtin/bugreport.c. The hook.c also does not depend on hook-list.h. It did in an earlier version of the greater series cfe853e66be was extracted from, but not anymore. We might end up needing that line again, but let's remove it for now. Reported-by: Mike Hommey <mh@glandium.org> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-21Merge branch 'js/scalar'Libravatar Junio C Hamano1-0/+9
Add pieces from "scalar" to contrib/. * js/scalar: scalar: implement the `version` command scalar: implement the `delete` command scalar: teach 'reconfigure' to optionally handle all registered enlistments scalar: allow reconfiguring an existing enlistment scalar: implement the `run` command scalar: teach 'clone' to support the --single-branch option scalar: implement the `clone` subcommand scalar: implement 'scalar list' scalar: let 'unregister' handle a deleted enlistment directory gracefully scalar: 'unregister' stops background maintenance scalar: 'register' sets recommended config and starts maintenance scalar: create test infrastructure scalar: start documenting the command scalar: create a rudimentary executable scalar: add a README with a roadmap
2021-12-21Merge branch 'jc/c99-var-decl-in-for-loop'Libravatar Junio C Hamano1-0/+1
Weather balloon to find compilers that do not grok variable declaration in the for() loop. * jc/c99-var-decl-in-for-loop: revision: use C99 declaration of variable in for() loop
2021-12-15Merge branch 'hn/reftable'Libravatar Junio C Hamano1-3/+50
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'Libravatar Junio C Hamano1-1/+1
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-04scalar: create a rudimentary executableLibravatar Johannes Schindelin1-0/+9
The idea of Scalar (https://github.com/microsoft/scalar), and before that, of VFS for Git, has always been to prove that Git _can_ scale, and to upstream whatever strategies have been demonstrated to help. With this patch, we start the journey from that C# project to move what is left to Git's own `contrib/` directory, reimplementing it in pure C, with the intention to facilitate integrating the functionality into core Git all while maintaining backwards-compatibility for existing Scalar users (which will be much easier when both live in the same worktree). It has always been the plan to contribute all of the proven strategies back to core Git. For example, while the virtual filesystem provided by VFS for Git helped the team developing the Windows operating system to move onto Git, while trying to upstream it we realized that it cannot be done: getting the virtual filesystem to work (which we only managed to implement fully on Windows, but not on, say, macOS or Linux), and the required server-side support for the GVFS protocol, made this not quite feasible. The Scalar project learned from that and tackled the problem with different tactics: instead of pretending to Git that the working directory is fully populated, it _specifically_ teaches Git about partial clone (which is based on VFS for Git's cache server), about sparse checkout (which VFS for Git tried to do transparently, in the file system layer), and regularly runs maintenance tasks to keep the repository in a healthy state. With partial clone, sparse checkout and `git maintenance` having been upstreamed, there is little left that `scalar.exe` does which `git.exe` cannot do. One such thing is that `scalar clone <url>` will automatically set up a partial, sparse clone, and configure known-helpful settings from the start. So let's bring this convenience into Git's tree. The idea here is that you can (optionally) build Scalar via make -C contrib/scalar/ This will build the `scalar` executable and put it into the contrib/scalar/ subdirectory. The slightly awkward addition of the `contrib/scalar/*` bits to the top-level `Makefile` are actually really required: we want to link to `libgit.a`, which means that we will need to use the very same `CFLAGS` and `LDFLAGS` as the rest of Git. An early development version of this patch tried to replicate all the conditional code in `contrib/scalar/Makefile` (e.g. `NO_POLL`) just like `contrib/svn-fe/Makefile` used to do before it was retired. It turned out to be quite the whack-a-mole game: the SHA-1-related flags, the flags enabling/disabling `compat/poll/`, `compat/regex/`, `compat/win32mmap.c` & friends depending on the current platform... To put it mildly: it was a major mess. Instead, this patch makes minimal changes to the top-level `Makefile` so that the bits in `contrib/scalar/` can be compiled and linked, and adds a `contrib/scalar/Makefile` that uses the top-level `Makefile` in a most minimal way to do the actual compiling. Note: With this commit, we only establish the infrastructure, no Scalar functionality is implemented yet; We will do that incrementally over the next few commits. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-03revision: use C99 declaration of variable in for() loopLibravatar Junio C Hamano1-0/+1
There are certain C99 features that might be nice to use in our code base, but we've hesitated to do so in order to avoid breaking compatibility with older compilers. But we don't actually know if people are even using pre-C99 compilers these days. One way to figure that out is to introduce a very small use of a feature, and see if anybody complains, and we've done so to probe the portability for a few features like "trailing comma in enum declaration", "designated initializer for struct", and "designated initializer for array". A few years ago, we tried to use a handy for (int i = 0; i < n; i++) use(i); to introduce a new variable valid only in the loop, but found that some compilers we cared about didn't like it back then. Two years is a long-enough time, so let's try it again. If this patch can survive a few releases without complaint, then we can feel more confident that variable declaration in for() loop is supported by the compilers our user base use. And if we do get complaints, then we'll have gained some data and we can easily revert this patch. Helped-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-01git-compat-util: add a test balloon for C99 supportLibravatar brian m. carlson1-1/+1
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 <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-29Merge branch 'ab/sh-retire-helper-functions'Libravatar Junio C Hamano1-16/+10
Make a few helper functions unused and then lose them. * ab/sh-retire-helper-functions: git-sh-setup: remove "sane_grep", it's not needed anymore git-sh-setup: remove unused sane_egrep() function git-instaweb: unconditionally assume that gitweb is mod_perl capable Makefile: remove $(NO_CURL) from $(SCRIPT_DEFINES) Makefile: remove $(GIT_VERSION) from $(SCRIPT_DEFINES) Makefile: move git-SCRIPT-DEFINES adjacent to $(SCRIPT_DEFINES)
2021-10-29Merge branch 'ab/make-sparse-for-real'Libravatar Junio C Hamano1-1/+1
Fix-up for a recent topic. * ab/make-sparse-for-real: Makefile: remove redundant GIT-CFLAGS dependency from "sparse"
2021-10-21Makefile: remove redundant GIT-CFLAGS dependency from "sparse"Libravatar Ævar Arnfjörð Bjarmason1-1/+1
The "sparse" target needed the GIT-CFLAGS dependency before my c234e8a0ecf (Makefile: make the "sparse" target non-.PHONY, 2021-09-23), but since then it depends on the corresponding *.o files, which in turn depend on the correct header files, as well as on GIT-CFLAGS. There's no need to re-state this dependency here. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-21git-sh-setup: remove "sane_grep", it's not needed anymoreLibravatar Ævar Arnfjörð Bjarmason1-5/+1
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 <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-21Makefile: remove $(NO_CURL) from $(SCRIPT_DEFINES)Libravatar Ævar Arnfjörð Bjarmason1-2/+1
Stop including $(NO_CURL) in $(SCRIPT_DEFINES). The "@NO_CURL@" replacement added in 6c5c62f3401 (Print an error if cloning a http repo and NO_CURL is set, 2006-02-15) has not been referenced by anything in-tree since 49eb8d39c78 (Remove contrib/examples/*, 2018-03-25). That commit removed the reference from contrib/examples/*, but this @@NO_CURL@@ hasn't been used since git-pull.sh was the primary entry point for "git pull". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-21Makefile: remove $(GIT_VERSION) from $(SCRIPT_DEFINES)Libravatar Ævar Arnfjörð Bjarmason1-1/+1
Remove the $(GIT_VERSION) from $(SCRIPT_DEFINES). Now every time HEAD changes in a development copy we don't need to re-build the scripts and script libraries. This has not been needed since 2b9391bc675 (Makefile: do not replace @@GIT_VERSION@@ in shell scripts, 2012-06-20). On my setup this changes the re-making of 44 targets in a development copy where moved HEAD to 27. The $(GIT_VERSION) was seemingly left here by mistake or omission. We didn't need it since 2b9391bc675, but in the later e4dd89ab984 (Makefile: update scripts when build-time parameters change, 2012-06-20) it was added to SCRIPT_DEFINES. The two were part of the same series of patches, and given the summary in [1] and [2] it looks like this was probably a case of some earlier version of a later patch being combined with an updated earlier patch. 1. https://lore.kernel.org/git/20120619232231.GA6328@sigill.intra.peff.net/ 2. https://lore.kernel.org/git/20120619232453.GB6496@sigill.intra.peff.net/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-21Makefile: move git-SCRIPT-DEFINES adjacent to $(SCRIPT_DEFINES)Libravatar Ævar Arnfjörð Bjarmason1-8/+7
When "GIT-SCRIPT-DEFINES" was added in e4dd89ab984 (Makefile: update scripts when build-time parameters change, 2012-06-20) the rules for generating the scripts themselves were moved further away from the "cmd_munge_script" added in 46bac904581 (Do not install shell libraries executable, 2010-01-31). Let's move these around so that the variables and defines needed by given targets immediately precede them. This is not needed for any subsequent changes to work, but makes the code consistent with how GIT-PERL-DEFINES is structured. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-18Merge branch 'js/retire-preserve-merges'Libravatar Junio C Hamano1-2/+0
The "--preserve-merges" option of "git rebase" has been removed. * js/retire-preserve-merges: sequencer: restrict scope of a formerly public function rebase: remove a no-longer-used function rebase: stop mentioning the -p option in comments rebase: remove obsolete code comment rebase: drop the internal `rebase--interactive` command git-svn: drop support for `--preserve-merges` rebase: drop support for `--preserve-merges` pull: remove support for `--rebase=preserve` tests: stop testing `git rebase --preserve-merges` remote: warn about unhandled branch.<name>.rebase values t5520: do not use `pull.rebase=preserve`
2021-10-13Merge branch 'ab/make-sparse-for-real'Libravatar Junio C Hamano1-3/+6
Prevent "make sparse" from running for the source files that haven't been modified. * ab/make-sparse-for-real: Makefile: make the "sparse" target non-.PHONY
2021-10-13Merge branch 'ab/config-based-hooks-1'Libravatar Junio C Hamano1-13/+15
Mostly preliminary clean-up in the hook API. * ab/config-based-hooks-1: hook-list.h: add a generated list of hooks, like config-list.h hook.c users: use "hook_exists()" instead of "find_hook()" hook.c: add a hook_exists() wrapper and use it in bugreport.c hook.[ch]: move find_hook() from run-command.c to hook.c Makefile: remove an out-of-date comment Makefile: don't perform "mv $@+ $@" dance for $(GENERATED_H) Makefile: stop hardcoding {command,config}-list.h Makefile: mark "check" target as .PHONY
2021-10-12Merge branch 'ab/make-clean-depend-dirs' into maintLibravatar Junio C Hamano1-1/+0
"make clean" has been updated to remove leftover .depend/ directories, even when it is not told to use them to compute header dependencies. * ab/make-clean-depend-dirs: Makefile: clean .depend dirs under COMPUTE_HEADER_DEPENDENCIES != yes
2021-10-12Merge branch 'ab/no-more-check-bindir' into maintLibravatar Junio C Hamano1-2/+1
Build simplification. * ab/no-more-check-bindir: Makefile: remove the check_bindir script
2021-10-12Merge branch 'sg/make-fix-ar-invocation' into maintLibravatar Junio C Hamano1-2/+2
Build fix. * sg/make-fix-ar-invocation: Makefile: remove archives before manipulating them with 'ar'
2021-10-11Merge branch 'ab/sanitize-leak-ci'Libravatar Junio C Hamano1-0/+5
CI learns to run the leak sanitizer builds. * ab/sanitize-leak-ci: tests: add a test mode for SANITIZE=leak, run it in CI Makefile: add SANITIZE=leak flag to GIT-BUILD-OPTIONS
2021-10-08Add "test-tool dump-reftable" command.Libravatar Han-Wen Nienhuys1-0/+1
This command dumps individual tables or a stack of of tables. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08reftable: implement stack, a mutable database of reftable files.Libravatar Han-Wen Nienhuys1-0/+1
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08reftable: implement refname validationLibravatar Han-Wen Nienhuys1-0/+1
The packed/loose format has restrictions on refnames: a and a/b cannot coexist. This limitation does not apply to reftable per se, but must be maintained for interoperability. This code adds validation routines to abort transactions that are trying to add invalid names. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08reftable: add merged table viewLibravatar Han-Wen Nienhuys1-0/+2
This adds an abstract, read-only interface to the ref database. This primitive is used to construct the read view of the ref database (the read view is constructed by merging several *.ref files). It also provides the mechanism to provide a unified view of the refs in the main repository and the per-worktree refs. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08reftable: add a heap-based priority queue for reftable recordsLibravatar Han-Wen Nienhuys1-0/+2
This is needed to create a merged view multiple reftables Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08reftable: reftable file level testsLibravatar Han-Wen Nienhuys1-0/+1
With support for reading and writing files in place, we can construct files (in memory) and attempt to read them back. Because some sections of the format are optional (eg. indices, log entries), we have to exercise this code using multiple sizes of input data Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08reftable: read reftable filesLibravatar Han-Wen Nienhuys1-0/+2
This supports reading a single reftable file. The commit introduces an abstract iterator type, which captures the usecases both of reading individual refs, and iterating over a segment of the ref namespace. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08reftable: generic interface to tablesLibravatar Han-Wen Nienhuys1-0/+3
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08reftable: write reftable filesLibravatar Han-Wen Nienhuys1-0/+1
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08reftable: a generic binary tree implementationLibravatar Han-Wen Nienhuys1-1/+3
The reftable format includes support for an (OID => ref) map. This map can speed up visibility and reachability checks. In particular, various operations along the fetch/push path within Gerrit have ben sped up by using this structure. The map is constructed with help of a binary tree. Object IDs are hashes, so they are uniformly distributed. Hence, the tree does not attempt forced rebalancing. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08reftable: reading/writing blocksLibravatar Han-Wen Nienhuys1-0/+2
The reftable format is structured as a sequence of block. Within a block, records are prefix compressed, with an index of offsets for fully expand keys to enable binary search within blocks. This commit provides the logic to read and write these blocks. Helped-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08Provide zlib's uncompress2 from compat/zlib-compat.cLibravatar Han-Wen Nienhuys1-0/+7
This will be needed for reading reflog blocks in reftable. Helped-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08reftable: (de)serialization for the polymorphic record type.Libravatar Han-Wen Nienhuys1-0/+2
The reftable format is structured as a sequence of blocks, and each block contains a sequence of prefix-compressed key-value records. There are 4 types of records, and they have similarities in how they must be handled. This is achieved by introducing a polymorphic 'record' type that encapsulates ref, log, index and object records. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08reftable: add blocksource, an abstraction for random access readsLibravatar Han-Wen Nienhuys1-0/+1
The reftable format is usually used with files for storage. However, we abstract away this using the blocksource data structure. This has two advantages: * log blocks are zlib compressed, and handling them is simplified if we can discard byte segments from within the block layer. * for unittests, it is useful to read and write in-memory. The blocksource allows us to abstract the data away from on-disk files. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-08reftable: utility functionsLibravatar Han-Wen Nienhuys1-3/+22
This commit provides basic utility classes for the reftable library. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-03Merge branch 'ab/make-compdb-fix'Libravatar Junio C Hamano1-0/+1
Build update. * ab/make-compdb-fix: Makefile: pass -Wno-pendantic under GENERATE_COMPILATION_DATABASE=yes
2021-10-03Merge branch 'ab/auto-depend-with-pedantic'Libravatar Junio C Hamano1-0/+1
Improve build procedure for developers. * ab/auto-depend-with-pedantic: Makefile: make COMPUTE_HEADER_DEPENDENCIES=auto work with DEVOPTS=pedantic
2021-10-03Merge branch 'ab/make-clean-depend-dirs'Libravatar Junio C Hamano1-1/+0
"make clean" has been updated to remove leftover .depend/ directories, even when it is not told to use them to compute header dependencies. * ab/make-clean-depend-dirs: Makefile: clean .depend dirs under COMPUTE_HEADER_DEPENDENCIES != yes
2021-09-27Makefile: pass -Wno-pendantic under GENERATE_COMPILATION_DATABASE=yesLibravatar Ævar Arnfjörð Bjarmason1-0/+1
The same bug fixed in the "COMPUTE_HEADER_DEPENDENCIES=auto" mode in the preceding commit was also present with "GENERATE_COMPILATION_DATABASE=yes". Let's fix it so it works again with "DEVOPTS=1". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-27hook-list.h: add a generated list of hooks, like config-list.hLibravatar Ævar Arnfjörð Bjarmason1-1/+7
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 <avarab@gmail.com> Helped-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-27hook.[ch]: move find_hook() from run-command.c to hook.cLibravatar Ævar Arnfjörð Bjarmason1-0/+1
Move the find_hook() function from run-command.c to a new hook.c library. This change establishes a stub library that's pretty pointless right now, but will see much wider use with Emily Shaffer's upcoming "configuration-based hooks" series. Eventually all the hook related code will live in hook.[ch]. Let's start that process by moving the simple find_hook() function over as-is. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-23Makefile: remove an out-of-date commentLibravatar Ævar Arnfjörð Bjarmason1-7/+0
This comment added in dfea575017 (Makefile: lazily compute header dependencies, 2010-01-26) has been out of date since 92b88eba9f (Makefile: use `git ls-files` to list header files, if possible, 2019-03-04), when we did exactly what it tells us not to do and added $(GENERATED_H) to $(OBJECTS) dependencies. The rest of it was also somewhere between inaccurate and outdated, since as of b8ba629264 (Makefile: fold MISC_H into LIB_H, 2012-06-20) it's not followed by a list of header files, that got moved earlier in the file into LIB_H in 60d24dd255 (Makefile: fold XDIFF_H and VCSSVN_H into LIB_H, 2012-07-06). Let's just remove it entirely, to the extent that we have anything useful to say here the comment on the "USE_COMPUTED_HEADER_DEPENDENCIES" variable a few lines above this change does the job for us. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-23Makefile: don't perform "mv $@+ $@" dance for $(GENERATED_H)Libravatar Ævar Arnfjörð Bjarmason1-3/+2
Change the "cmd.sh > $@+ && mv $@+ $@" pattern used for generating the config-list.h and command-list.h to just "cmd.sh >$@". This was needed as a guard to ensure that we don't have an empty file if the script failed, but since 7b76d6bf221 (Makefile: add and use the ".DELETE_ON_ERROR" flag, 2021-06-29) GNU make ensures that doesn't happen. There's still a lot of other places in the Makefile where we needlessly use this pattern, but I'm just changing these because I'm about to add a new $(GENERATED_H) target, let's have them all look and act the same way. Even with ".DELETE_ON_ERROR" there is still a point to using the "mv $@+ $@" pattern in some cases, e.g. to ensure that you have a working binary during recompilation (see [1] for the start of a long discussion about that), but that doesn't apply here. Nothing external uses $(GENERATED_H) directly, it's only ever used in the context of the Makefile's own dependency (re-)generation. 1. https://lore.kernel.org/git/8735t93h0u.fsf@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>