summaryrefslogtreecommitdiff
path: root/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2020-11-21Merge branch 'en/strmap'Libravatar Junio C Hamano1-0/+1
A specialization of hashmap that uses a string as key has been introduced. Hopefully it will see wider use over time. * en/strmap: shortlog: use strset from strmap.h Use new HASHMAP_INIT macro to simplify hashmap initialization strmap: take advantage of FLEXPTR_ALLOC_STR when relevant strmap: enable allocations to come from a mem_pool strmap: add a strset sub-type strmap: split create_entry() out of strmap_put() strmap: add functions facilitating use as a string->int map strmap: enable faster clearing and reusing of strmaps strmap: add more utility functions strmap: new utility functions hashmap: provide deallocation function names hashmap: introduce a new hashmap_partial_clear() hashmap: allow re-use after hashmap_free() hashmap: adjust spacing to fix argument alignment hashmap: add usage documentation explaining hashmap_free[_entries]()
2020-11-18Merge branch 'en/merge-ort-api-null-impl'Libravatar Junio C Hamano1-0/+3
Preparation for a new merge strategy. * en/merge-ort-api-null-impl: merge,rebase,revert: select ort or recursive by config or environment fast-rebase: demonstrate merge-ort's API via new test-tool command merge-ort-wrappers: new convience wrappers to mimic the old merge API merge-ort: barebones API of new merge strategy with empty implementation
2020-11-18Merge branch 'ds/maintenance-part-3'Libravatar Junio C Hamano1-0/+2
Parts of "git maintenance" to ease writing crontab entries (and other scheduling system configuration) for it. * ds/maintenance-part-3: maintenance: add troubleshooting guide to docs maintenance: use 'incremental' strategy by default maintenance: create maintenance.strategy config maintenance: add start/stop subcommands maintenance: add [un]register subcommands for-each-repo: run subcommands on configured repos maintenance: add --schedule option and config maintenance: optionally skip --auto process
2020-11-09Merge branch 'jk/perl-warning'Libravatar Junio C Hamano1-0/+3
Dev support. * jk/perl-warning: perl: check for perl warnings while running tests
2020-11-02strmap: new utility functionsLibravatar Elijah Newren1-0/+1
Add strmap as a new struct and associated utility functions, specifically for hashmaps that map strings to some value. The API is taken directly from Peff's proposal at https://lore.kernel.org/git/20180906191203.GA26184@sigill.intra.peff.net/ Note that similar string-list, I have a strdup_strings setting. However, unlike string-list, strmap_init() does not take a parameter for this setting and instead automatically sets it to 1; callers who want to control this detail need to instead call strmap_init_with_options(). (Future patches will add additional parameters to strmap_init_with_options()). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-29fast-rebase: demonstrate merge-ort's API via new test-tool commandLibravatar Elijah Newren1-0/+1
Add a new test-tool command named 'fast-rebase', which is a super-slimmed down and nowhere near as capable version of 'git rebase'. 'test-tool fast-rebase' is not currently planned for usage in the testsuite, but is here for two purposes: 1) Demonstrate the desired API of merge-ort. In particular, fast-rebase takes advantage of the separation of the merging operation from the updating of the index and working tree, to allow it to pick N commits, but only update the index and working tree once at the end. Look for the calls to merge_incore_nonrecursive() and merge_switch_to_result(). 2) Provide a convenient benchmark that isn't polluted by the heavy disk writing and forking of unnecessary processes that comes from sequencer.c and merge-recursive.c. fast-rebase is not meant to replace sequencer.c, just give ideas on how sequencer.c can be changed. Updating sequencer.c with these goals is probably a large amount of work; writing a simple targeted command with no documentation, less-than-useful help messages, numerous limitations in terms of flags it can accept and situations it can handle, and which is flagged off from users is a much easier interim step. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-27Merge branch 'rs/dist-doc-with-git-archive'Libravatar Junio C Hamano1-6/+11
Use "git archive" more to produce the release tarball. * rs/dist-doc-with-git-archive: Makefile: remove the unused variable TAR_DIST_EXTRA_OPTS Makefile: use git init/add/commit/archive for dist-doc
2020-10-26merge-ort-wrappers: new convience wrappers to mimic the old merge APILibravatar Elijah Newren1-0/+1
There are a few differences between the new API in merge-ort and the old API in merge-recursive. While the new API is more flexible, it might feel like more work at times than the old API. merge-ort-wrappers creates two convenience wrappers taking the exact same arguments as the old merge_trees() and merge_recursive() functions and implements them via the new API. This makes converting existing callsites easier, and serves to highlight some of the differences in the API. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26merge-ort: barebones API of new merge strategy with empty implementationLibravatar Elijah Newren1-0/+1
This is the beginning of a new merge strategy. While there are some API differences, and the implementation has some differences in behavior, it is essentially meant as an eventual drop-in replacement for merge-recursive.c. However, it is being built to exist side-by-side with merge-recursive so that we have plenty of time to find out how those differences pan out in the real world while people can still fall back to merge-recursive. (Also, I intend to avoid modifying merge-recursive during this process, to keep it stable.) The primary difference noticable here is that the updating of the working tree and index is not done simultaneously with the merge algorithm, but is a separate post-processing step. The new API is designed so that one can do repeated merges (e.g. during a rebase or cherry-pick) and only update the index and working tree one time at the end instead of updating it with every intermediate result. Also, one can perform a merge between two branches, neither of which match the index or the working tree, without clobbering the index or working tree. The next three commits will demonstrate various uses of this new API. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-22Merge branch 'js/no-builtins-on-disk-option' into maintLibravatar Junio C Hamano1-9/+6
Brown-paper-bag fix. * js/no-builtins-on-disk-option: SKIP_DASHED_BUILT_INS: do not skip the bin/ programs
2020-10-21perl: check for perl warnings while running testsLibravatar Jeff King1-0/+3
We set "use warnings" in most of our perl code to catch problems. But as the name implies, warnings just emit a message to stderr and don't otherwise affect the program. So our tests are quite likely to miss that warnings are being spewed, as most of them do not look at stderr. We could ask perl to make all warnings fatal, but this is likely annoying for non-developers, who would rather have a running program with a warning than something that refuses to work at all. So instead, let's teach the perl code to respect an environment variable (GIT_PERL_FATAL_WARNINGS) to increase the severity of the warnings. This can be set for day-to-day running if people want to be really pedantic, but the primary use is to trigger it within the test suite. We could also trigger that for every test run, but likewise even the tests failing may be annoying to distro builders, etc (just as -Werror would be for compiling C code). So we'll tie it to a special test-mode variable (GIT_TEST_PERL_FATAL_WARNINGS) that can be set in the environment or as a Makefile knob, and we'll automatically turn the knob when DEVELOPER=1 is set. That should give developers and CI the more careful view without disrupting normal users or packagers. Note that the mapping from the GIT_TEST_* form to the GIT_* form in test-lib.sh is necessary even if they had the same name: the perl scripts need it to be normalized to a perl truth value, and we also have to make sure it's exported (we might have gotten it from the environment, but we might also have gotten it from GIT-BUILD-OPTIONS directly). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-21SKIP_DASHED_BUILT_INS: do not skip the bin/ programsLibravatar Johannes Schindelin1-9/+6
The idea of the `SKIP_DASHED_BUILT_INS` option is to stop hard-linking the built-in commands as separate executables. The patches to do that specifically excluded the three commands `receive-pack`, `upload-archive` and `upload-pack`, though: these commands are expected to be present in the `PATH` in their dashed form on the server side of any fetch/push. However, due to an oversight by myself, even if those commands were still hard-linked, they were not installed into `bin/`. Noticed-by: Michael Forney <mforney@mforney.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-12Makefile: remove the unused variable TAR_DIST_EXTRA_OPTSLibravatar René Scharfe1-3/+0
Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-12Makefile: use git init/add/commit/archive for dist-docLibravatar René Scharfe1-3/+11
Reduce the dependency on external tools by generating the distribution archives for HTML documentation and manpages using git commands instead of tar. This gives the archive entries the same meta data as those in the dist archive for binaries. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08Makefile: ASCII-sort += listsLibravatar Denton Liu1-5/+5
In 805d9eaf5e (Makefile: ASCII-sort += lists, 2020-03-21), the += lists in the Makefile were sorted into ASCII order. Since then, more out of order elements have been introduced. Sort these lists back into ASCII order. This patch is best viewed with `--color-moved`. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-05Merge branch 'rs/archive-add-file'Libravatar Junio C Hamano1-22/+19
"git archive" learns the "--add-file" option to include untracked files into a snapshot from a tree-ish. * rs/archive-add-file: Makefile: use git-archive --add-file archive: add --add-file archive: read short blobs in archive.c::write_archive_entry()
2020-10-04Merge branch 'jk/drop-unaligned-loads'Libravatar Junio C Hamano1-1/+0
Compilation fix around type punning. * jk/drop-unaligned-loads: Revert "fast-export: use local array to store anonymized oid" bswap.h: drop unaligned loads
2020-10-04Merge branch 'js/no-builtins-on-disk-option'Libravatar Junio C Hamano1-27/+39
The installation procedure learned to optionally omit "git-foo" executable files for each 'foo' built-in subcommand, which are only required by old timers that still rely on the age old promise that prepending "git --exec-path" output to PATH early in their script will keep the "git-foo" calls they wrote working. The old attempt to remove these executables from the disk failed in the 1.6 era; it may be worth attempting again, but I think it is worth to keep this topic separate from such a policy change to help it graduate early. * js/no-builtins-on-disk-option: ci: stop linking built-ins to the dashed versions Optionally skip linking/copying the built-ins msvc: copy the correct `.pdb` files in the Makefile target `install`
2020-09-25Merge branch 'jx/proc-receive-hook'Libravatar Junio C Hamano1-0/+1
"git receive-pack" that accepts requests by "git push" learned to outsource most of the ref updates to the new "proc-receive" hook. * jx/proc-receive-hook: doc: add documentation for the proc-receive hook transport: parse report options for tracking refs t5411: test updates of remote-tracking branches receive-pack: new config receive.procReceiveRefs doc: add document for capability report-status-v2 New capability "report-status-v2" for git-push receive-pack: feed report options to post-receive receive-pack: add new proc-receive hook t5411: add basic test cases for proc-receive hook transport: not report a non-head push as a branch
2020-09-25maintenance: add start/stop subcommandsLibravatar Derrick Stolee1-0/+1
Add new subcommands to 'git maintenance' that start or stop background maintenance using 'cron', when available. This integration is as simple as I could make it, barring some implementation complications. The schedule is laid out as follows: 0 1-23 * * * $cmd maintenance run --schedule=hourly 0 0 * * 1-6 $cmd maintenance run --schedule=daily 0 0 * * 0 $cmd maintenance run --schedule=weekly where $cmd is a properly-qualified 'git for-each-repo' execution: $cmd=$path/git --exec-path=$path for-each-repo --config=maintenance.repo where $path points to the location of the Git executable running 'git maintenance start'. This is critical for systems with multiple versions of Git. Specifically, macOS has a system version at '/usr/bin/git' while the version that users can install resides at '/usr/local/bin/git' (symlinked to '/usr/local/libexec/git-core/git'). This will also use your locally-built version if you build and run this in your development environment without installing first. This conditional schedule avoids having cron launch multiple 'git for-each-repo' commands in parallel. Such parallel commands would likely lead to the 'hourly' and 'daily' tasks competing over the object database lock. This could lead to to some tasks never being run! Since the --schedule=<frequency> argument will run all tasks with _at least_ the given frequency, the daily runs will also run the hourly tasks. Similarly, the weekly runs will also run the daily and hourly tasks. The GIT_TEST_CRONTAB environment variable is not intended for users to edit, but instead as a way to mock the 'crontab [-l]' command. This variable is set in test-lib.sh to avoid a future test from accidentally running anything with the cron integration from modifying the user's schedule. We use GIT_TEST_CRONTAB='test-tool crontab <file>' in our tests to check how the schedule is modified in 'git maintenance (start|stop)' commands. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-25for-each-repo: run subcommands on configured reposLibravatar Derrick Stolee1-0/+1
It can be helpful to store a list of repositories in global or system config and then iterate Git commands on that list. Create a new builtin that makes this process simple for experts. We will use this builtin to run scheduled maintenance on all configured repositories in a future change. The test is very simple, but does highlight that the "--" argument is optional. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-24bswap.h: drop unaligned loadsLibravatar Jeff King1-1/+0
Our put_be32() routine and its variants (get_be32(), put_be64(), etc) has two implementations: on some platforms we cast memory in place and use nothl()/htonl(), which can cause unaligned memory access. And on others, we pick out the individual bytes using bitshifts. This introduces extra complexity, and sometimes causes compilers to generate warnings about type-punning. And it's not clear there's any performance advantage. This split goes back to 660231aa97 (block-sha1: support for architectures with memory alignment restrictions, 2009-08-12). The unaligned versions were part of the original block-sha1 code in d7c208a92e (Add new optimized C 'block-sha1' routines, 2009-08-05), which says it is: Based on the mozilla SHA1 routine, but doing the input data accesses a word at a time and with 'htonl()' instead of loading bytes and shifting. Back then, Linus provided timings versus the mozilla code which showed a 27% improvement: https://lore.kernel.org/git/alpine.LFD.2.01.0908051545000.3390@localhost.localdomain/ However, the unaligned loads were either not the useful part of that speedup, or perhaps compilers and processors have changed since then. Here are times for computing the sha1 of 4GB of random data, with and without -DNO_UNALIGNED_LOADS (and BLK_SHA1=1, of course). This is with gcc 10, -O2, and the processor is a Core i9-9880H. [stock] Benchmark #1: t/helper/test-tool sha1 <foo.rand Time (mean ± σ): 6.638 s ± 0.081 s [User: 6.269 s, System: 0.368 s] Range (min … max): 6.550 s … 6.841 s 10 runs [-DNO_UNALIGNED_LOADS] Benchmark #1: t/helper/test-tool sha1 <foo.rand Time (mean ± σ): 6.418 s ± 0.015 s [User: 6.058 s, System: 0.360 s] Range (min … max): 6.394 s … 6.447 s 10 runs And here's the same test run on an AMD A8-7600, using gcc 8. [stock] Benchmark #1: t/helper/test-tool sha1 <foo.rand Time (mean ± σ): 11.721 s ± 0.113 s [User: 10.761 s, System: 0.951 s] Range (min … max): 11.509 s … 11.861 s 10 runs [-DNO_UNALIGNED_LOADS] Benchmark #1: t/helper/test-tool sha1 <foo.rand Time (mean ± σ): 11.744 s ± 0.066 s [User: 10.807 s, System: 0.928 s] Range (min … max): 11.637 s … 11.863 s 10 runs So the unaligned loads don't seem to help much, and actually make things worse. It's possible there are platforms where they provide more benefit, but: - the non-x86 platforms for which we use this code are old and obscure (powerpc and s390). - the main caller that cares about performance is block-sha1. But these days it is rarely used anyway, in favor of sha1dc (which is already much slower, and nobody seems to have cared that much). Let's just drop unaligned versions entirely in the name of simplicity. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-22Merge branch 'hn/refs-trace-backend'Libravatar Junio C Hamano1-0/+1
Developer support. * hn/refs-trace-backend: refs: add GIT_TRACE_REFS debugging mechanism
2020-09-22Merge branch 'es/format-patch-interdiff-cleanup'Libravatar Junio C Hamano1-1/+0
"format-patch --range-diff=<prev> <origin>..HEAD" has been taught not to ignore <origin> when <prev> is a single version. * es/format-patch-interdiff-cleanup: format-patch: use 'origin' as start of current-series-range when known diff-lib: tighten show_interdiff()'s interface diff: move show_interdiff() from its own file to diff-lib
2020-09-21Optionally skip linking/copying the built-insLibravatar Johannes Schindelin1-18/+37
For a long time already, the non-dashed form of the built-ins is the recommended way to write scripts, i.e. it is better to call `git merge [...]` than to call `git-merge [...]`. While Git still supports the dashed form (by hard-linking the `git` executable to the dashed name in `libexec/git-core/`), in practice, it is probably almost irrelevant. However, we *do* care about keeping people's scripts working (even if they were written before the non-dashed form started to be recommended). Keeping this backwards-compatibility is not necessarily cheap, though: even so much as amending the tip commit in a git.git checkout will require re-linking all of those dashed commands. On this developer's laptop, this makes a noticeable difference: $ touch version.c && time make CC version.o AR libgit.a LINK git-bugreport.exe [... 11 similar lines ...] LN/CP git-remote-https.exe LN/CP git-remote-ftp.exe LN/CP git-remote-ftps.exe LINK git.exe BUILTIN git-add.exe [... 123 similar lines ...] BUILTIN all SUBDIR git-gui SUBDIR gitk-git SUBDIR templates LINK t/helper/test-fake-ssh.exe LINK t/helper/test-line-buffer.exe LINK t/helper/test-svn-fe.exe LINK t/helper/test-tool.exe real 0m36.633s user 0m3.794s sys 0m14.141s $ touch version.c && time make SKIP_DASHED_BUILT_INS=1 CC version.o AR libgit.a LINK git-bugreport.exe [... 11 similar lines ...] LN/CP git-remote-https.exe LN/CP git-remote-ftp.exe LN/CP git-remote-ftps.exe LINK git.exe BUILTIN git-receive-pack.exe BUILTIN git-upload-archive.exe BUILTIN git-upload-pack.exe BUILTIN all SUBDIR git-gui SUBDIR gitk-git SUBDIR templates LINK t/helper/test-fake-ssh.exe LINK t/helper/test-line-buffer.exe LINK t/helper/test-svn-fe.exe LINK t/helper/test-tool.exe real 0m23.717s user 0m1.562s sys 0m5.210s Also, `.zip` files do not have any standardized support for hard-links, therefore "zipping up" the executables will result in inflated disk usage. (To keep down the size of the "MinGit" variant of Git for Windows, which is distributed as a `.zip` file, the hard-links are excluded specifically.) In addition to that, some programs that are regularly used to assess disk usage fail to realize that those are hard-links, and heavily overcount disk usage. Most notably, this was the case with Windows Explorer up until the last couple of Windows 10 versions. See e.g. https://github.com/msysgit/msysgit/issues/58. To save on the time needed to hard-link these dashed commands, with the plan to eventually stop shipping with those hard-links on Windows, let's introduce a Makefile knob to skip generating them. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21msvc: copy the correct `.pdb` files in the Makefile target `install`Libravatar Johannes Schindelin1-9/+2
There is a hard-coded list of `.pdb` files to copy. But we are about to introduce the `SKIP_DASHED_BUILT_INS` knob in the `Makefile`, which might make this hard-coded list incorrect. Let's switch to a dynamically-generated list instead. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-19Makefile: use git-archive --add-fileLibravatar René Scharfe1-22/+19
Add untracked files for the dist target directly using git archive instead of calling tar cr to append them. This reduces the dependency on external tools and gives the untracked files the same access times and user information as tracked ones, integrating them seamlessly. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-18Merge branch 'jc/dist-tarball-tweak'Libravatar Junio C Hamano1-4/+7
Allow maintainers to tweak $(TAR) invocations done while making distribution tarballs. * jc/dist-tarball-tweak: Makefile: allow extra tweaking of distribution tarball
2020-09-18Merge branch 'pb/clang-json-compilation-database'Libravatar Junio C Hamano1-5/+54
Developer support. * pb/clang-json-compilation-database: Makefile: add support for generating JSON compilation database
2020-09-09refs: add GIT_TRACE_REFS debugging mechanismLibravatar Han-Wen Nienhuys1-0/+1
When set in the environment, GIT_TRACE_REFS makes git print operations and results as they flow through the ref storage backend. This helps debug discrepancies between different ref backends. Example: $ GIT_TRACE_REFS="1" ./git branch 15:42:09.769631 refs/debug.c:26 ref_store for .git 15:42:09.769681 refs/debug.c:249 read_raw_ref: HEAD: 0000000000000000000000000000000000000000 (=> refs/heads/ref-debug) type 1: 0 15:42:09.769695 refs/debug.c:249 read_raw_ref: refs/heads/ref-debug: 3a238e539bcdfe3f9eb5010fd218640c1b499f7a (=> refs/heads/ref-debug) type 0: 0 15:42:09.770282 refs/debug.c:233 ref_iterator_begin: refs/heads/ (0x1) 15:42:09.770290 refs/debug.c:189 iterator_advance: refs/heads/b4 (0) 15:42:09.770295 refs/debug.c:189 iterator_advance: refs/heads/branch3 (0) Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-09Makefile: allow extra tweaking of distribution tarballLibravatar Junio C Hamano1-4/+7
The maintainer's dist rules are used to produce distribution tarballs. They use "$(TAR) cf" and "$(TAR) rf" to produce archives out of a freshly created local installation area, which means that the built product can be affected by maintainer's umask and other local environment. Implementations of "tar" have ways (implementation specific, unfortunately) to force permission bits and other stuff to allow the user to hide these effects coming from the local environment. Teach our Makefile to allow the maintainer to tweak the invocation of the $(TAR) commands by setting TAR_DIST_EXTRA_OPTS. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-08diff: move show_interdiff() from its own file to diff-libLibravatar Eric Sunshine1-1/+0
show_interdiff() is a relatively small function and not likely to grow larger or more complicated. Rather than dedicating an entire source file to it, relocate it to diff-lib.c which houses other "take two things and compare them" functions meant to be re-used but not so low-level as to reside in the core diff implementation. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-06Makefile: add support for generating JSON compilation databaseLibravatar Philippe Blain1-5/+54
Tools based on LibClang [1] can make use of a 'JSON Compilation Database' [2] that keeps track of the exact options used to compile a set of source files. For example, clangd [3], which is a C language server protocol implementation, can use a JSON compilation database to determine the flags needed to compile a file so it can provide proper editor integration. As a result, editors supporting the language server protocol (such as VS Code, Emacs, or Vim, with suitable plugins) can provide better searching, integration, and refactoring tools. The Clang compiler can generate JSON fragments when compiling [4], using the `-MJ` flag. These JSON fragments (one per compiled source file) can then be concatenated to create the compilation database, commonly called 'compile_commands.json'. Add support to the Makefile for generating these JSON fragments as well as the compilation database itself, if the environment variable 'GENERATE_COMPILATION_DATABASE' is set. If this variable is set, check that $(CC) indeed supports the `-MJ` flag, following what is done for automatic dependencies. All JSON fragments are placed in the 'compile_commands/' directory, and the compilation database 'compile_commands.json' is generated as a dependency of the 'all' target using a `sed` invocation. [1] https://clang.llvm.org/docs/Tooling.html [2] https://clang.llvm.org/docs/JSONCompilationDatabase.html [3] https://clangd.llvm.org/ [4] https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-mj-arg Helped-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-03Merge branch 'jt/lazy-fetch'Libravatar Junio C Hamano1-0/+1
Updates to on-demand fetching code in lazily cloned repositories. * jt/lazy-fetch: fetch: no FETCH_HEAD display if --no-write-fetch-head fetch-pack: remove no_dependents code promisor-remote: lazy-fetch objects in subprocess fetch-pack: do not lazy-fetch during ref iteration fetch: only populate existing_refs if needed fetch: avoid reading submodule config until needed fetch: allow refspecs specified through stdin negotiator/noop: add noop fetch negotiator
2020-08-27receive-pack: add new proc-receive hookLibravatar Jiang Xin1-0/+1
Git calls an internal `execute_commands` function to handle commands sent from client to `git-receive-pack`. Regardless of what references the user pushes, git creates or updates the corresponding references if the user has write-permission. A contributor who has no write-permission, cannot push to the repository directly. So, the contributor has to write commits to an alternate location, and sends pull request by emails or by other ways. We call this workflow as a distributed workflow. It would be more convenient to work in a centralized workflow like what Gerrit provided for some cases. For example, a read-only user who cannot push to a branch directly can run the following `git push` command to push commits to a pseudo reference (has a prefix "refs/for/", not "refs/heads/") to create a code review. git push origin \ HEAD:refs/for/<branch-name>/<session> The `<branch-name>` in the above example can be as simple as "master", or a more complicated branch name like "foo/bar". The `<session>` in the above example command can be the local branch name of the client side, such as "my/topic". We cannot implement a centralized workflow elegantly by using "pre-receive" + "post-receive", because Git will call the internal function "execute_commands" to create references (even the special pseudo reference) between these two hooks. Even though we can delete the temporarily created pseudo reference via the "post-receive" hook, having a temporary reference is not safe for concurrent pushes. So, add a filter and a new handler to support this kind of workflow. The filter will check the prefix of the reference name, and if the command has a special reference name, the filter will turn a specific field (`run_proc_receive`) on for the command. Commands with this filed turned on will be executed by a new handler (a hook named "proc-receive") instead of the internal `execute_commands` function. We can use this "proc-receive" command to create pull requests or send emails for code review. Suggested by Junio, this "proc-receive" hook reads the commands, push-options (optional), and send result using a protocol in pkt-line format. In the following example, the letter "S" stands for "receive-pack" and letter "H" stands for the hook. # Version and features negotiation. S: PKT-LINE(version=1\0push-options atomic...) S: flush-pkt H: PKT-LINE(version=1\0push-options...) H: flush-pkt # Send commands from server to the hook. S: PKT-LINE(<old-oid> <new-oid> <ref>) S: ... ... S: flush-pkt # Send push-options only if the 'push-options' feature is enabled. S: PKT-LINE(push-option) S: ... ... S: flush-pkt # Receive result from the hook. # OK, run this command successfully. H: PKT-LINE(ok <ref>) # NO, I reject it. H: PKT-LINE(ng <ref> <reason>) # Fall through, let 'receive-pack' to execute it. H: PKT-LINE(ok <ref>) H: PKT-LINE(option fall-through) # OK, but has an alternate reference. The alternate reference name # and other status can be given in options H: PKT-LINE(ok <ref>) H: PKT-LINE(option refname <refname>) H: PKT-LINE(option old-oid <old-oid>) H: PKT-LINE(option new-oid <new-oid>) H: PKT-LINE(option forced-update) H: ... ... H: flush-pkt After receiving a command, the hook will execute the command, and may create/update different reference. For example, a command for a pseudo reference "refs/for/master/topic" may create/update different reference such as "refs/pull/123/head". The alternate reference name and other status are given in option lines. The list of commands returned from "proc-receive" will replace the relevant commands that are sent from user to "receive-pack", and "receive-pack" will continue to run the "execute_commands" function and other routines. Finally, the result of the execution of these commands will be reported to end user. The reporting function from "receive-pack" to "send-pack" will be extended in latter commit just like what the "proc-receive" hook reports to "receive-pack". Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-18negotiator/noop: add noop fetch negotiatorLibravatar Jonathan Tan1-0/+1
Add a noop fetch negotiator. This is introduced to allow partial clones to skip the unneeded negotiation step when fetching missing objects using a "git fetch" subprocess. (The implementation of spawning a "git fetch" subprocess will be done in a subsequent patch.) But this can also be useful for end users, e.g. as a blunt fix for object corruption. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-13drop vcs-svn experimentLibravatar Jeff King1-25/+1
The code in vcs-svn was started in 2010 as an attempt to build a remote-helper for interacting with svn repositories (as opposed to git-svn). However, we never got as far as shipping a mature remote helper, and the last substantive commit was e99d012a6bc in 2012. We do have a git-remote-testsvn, and it is even installed as part of "make install". But given the name, it seems unlikely to be used by anybody (you'd have to explicitly "git clone testsvn::$url", and there have been zero mentions of that on the mailing list since 2013, and even that includes the phrase "you might need to hack a bit to get it working properly"[1]). We also ship contrib/svn-fe, which builds on the vcs-svn work. However, it does not seem to build out of the box for me, as the link step misses some required libraries for using libgit.a. Curiously, the original build breakage bisects for me to eff80a9fd9 (Allow custom "comment char", 2013-01-16), which seems unrelated. There was an attempt to fix it in da011cb0e7 (contrib/svn-fe: fix Makefile, 2014-08-28), but on my system that only switches the error message. So it seems like the result is not really usable by anybody in practice. It would be wonderful if somebody wanted to pick up the topic again, and potentially it's worth carrying around for that reason. But the flip side is that people doing tree-wide operations have to deal with this code. And you can see the list with (replace "HEAD" with this commit as appropriate): { echo "--" git diff-tree --diff-filter=D -r --name-only HEAD^ HEAD } | git log --no-merges --oneline e99d012a6bc.. --stdin which shows 58 times somebody had to deal with the code, generally due to a compile or test failure, or a tree-wide style fix or API change. Let's drop it and let anybody who wants to pick it up do so by resurrecting it from the git history. As a bonus, this also reduces the size of a stripped installation of Git from 21MB to 19MB. [1] https://lore.kernel.org/git/CALkWK0mPHzKfzFKKpZkfAus3YVC9NFYDbFnt+5JQYVKipk3bQQ@mail.gmail.com/ Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-13make git-fast-import a builtinLibravatar Jeff King1-2/+1
There's no reason that git-fast-import benefits from being a separate binary. And as it links against libgit.a, it has a non-trivial disk footprint. Let's make it a builtin, which reduces the size of a stripped installation from 22MB to 21MB. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-13make git-bugreport a builtinLibravatar Jeff King1-5/+1
There's no reason that bugreport has to be a separate binary. And since it links against libgit.a, it has a rather large disk footprint. Let's make it a builtin, which reduces the size of a stripped installation from 24MB to 22MB. This also simplifies our Makefile a bit. And we can take advantage of builtin niceties like RUN_SETUP_GENTLY. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-13make credential helpers builtinsLibravatar Jeff King1-5/+3
There's no real reason for credential helpers to be separate binaries. I did them this way originally under the notion that helper don't _need_ to be part of Git, and so can be built totally separately (and indeed, the ones in contrib/credential are). But the ones in our main Makefile build on libgit.a, and the resulting binaries are reasonably large. We can slim down our total disk footprint by just making them builtins. This reduces the size of: make strip install from 29MB to 24MB on my Debian system. Note that credential-cache can't operate without support for Unix sockets. Currently we just don't build it at all when NO_UNIX_SOCKETS is set. We could continue that with conditionals in the Makefile and our list of builtins. But instead, let's build a dummy implementation that dies with an informative message. That has two advantages: - it's simpler, because the conditional bits are all kept inside the credential-cache source - a user who is expecting it to exist will be told _why_ they can't use it, rather than getting the "credential-cache is not a git command" error which makes it look like the Git install is broken. Note that our dummy implementation does still respond to "-h" in order to appease t0012 (and this may be a little friendlier for users, as well). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-13Makefile: drop builtins from MSVC pdb listLibravatar Jeff King1-2/+0
Over the years some more programs have become builtins, but nobody updated this MSVC-specific section of the file (which specifically says that it should not include builtins). Let's bring it up to date. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28strvec: rename files from argv-array to strvecLibravatar Jeff King1-1/+1
This requires updating #include lines across the code-base, but that's all fairly mechanical, and was done with: git ls-files '*.c' '*.h' | xargs perl -i -pe 's/argv-array.h/strvec.h/' Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-02Merge branch 'lo/sparse-universal-zero-init'Libravatar Junio C Hamano1-1/+1
We've adopted a convention that any on-stack structure can be initialized to have zero values in all fields with "= { 0 }", even when the first field happens to be a pointer, but sparse complained that a null pointer should be spelled NULL for a long time. Start using -Wno-universal-initializer option to squelch it. * lo/sparse-universal-zero-init: sparse: allow '{ 0 }' to be used without warnings
2020-05-24sparse: allow '{ 0 }' to be used without warningsLibravatar Luc Van Oostenryck1-1/+1
In standard C, '{ 0 }' can be used as an universal zero-initializer. However, Sparse complains if this is used on a type where the first member (possibly nested) is a pointer since Sparse purposely wants to warn when '0' is used to initialize a pointer type. Legitimaly, it's desirable to be able to use '{ 0 }' as an idiom without these warnings [1,2]. To allow this, an option have now been added to Sparse: 537e3e2dae univ-init: conditionally accept { 0 } without warnings So, add this option to the SPARSE_FLAGS variable. Note: The option have just been added to Sparse. So, to benefit now from this patch it's needed to use the latest Sparse source from kernel.org. The option will simply be ignored by older versions of Sparse. [1] https://lore.kernel.org/r/e6796c60-a870-e761-3b07-b680f934c537@ramsayjones.plus.com [2] https://lore.kernel.org/r/xmqqd07xem9l.fsf@gitster.c.googlers.com Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-20Merge branch 'cb/no-more-gmtime'Libravatar Junio C Hamano1-8/+0
Code clean-up by removing a compatibility implementation of a function we no longer use. * cb/no-more-gmtime: compat: remove gmtime
2020-05-14compat: remove gmtimeLibravatar Carlo Marcelo Arenas Belón1-8/+0
ccd469450a (date.c: switch to reentrant {gm,local}time_r, 2019-11-28) removes the only gmtime() call we had and moves to gmtime_r() which doesn't have the same portability problems. Remove the compat gmtime code since it is no longer needed, and confirm by successfull running t4212 in FreeBSD 9.3 amd64 (the oldest I could get a hold off). Further work might be needed to ensure 32bit time_t systems (like FreeBSD i386) will handle correctly the overflows tested in t4212, but that is orthogonal to this change, and it doesn't change the current behaviour as neither gmtime() or gmtime_r() will ever return NULL on those systems because time_t is unsigned. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-01Merge branch 'es/bugreport'Libravatar Junio C Hamano1-3/+15
The "bugreport" tool. * es/bugreport: bugreport: drop extraneous includes bugreport: add compiler info bugreport: add uname info bugreport: gather git version and build info bugreport: add tool to generate debugging info help: move list_config_help to builtin/help
2020-05-01Merge branch 'gs/commit-graph-path-filter'Libravatar Junio C Hamano1-0/+2
Introduce an extension to the commit-graph to make it efficient to check for the paths that were modified at each commit using Bloom filters. * gs/commit-graph-path-filter: bloom: ignore renames when computing changed paths commit-graph: add GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS test flag t4216: add end to end tests for git log with Bloom filters revision.c: add trace2 stats around Bloom filter usage revision.c: use Bloom filters to speed up path based revision walks commit-graph: add --changed-paths option to write subcommand commit-graph: reuse existing Bloom filters during write commit-graph: write Bloom filters to commit graph file commit-graph: examine commits by generation number commit-graph: examine changed-path objects in pack order commit-graph: compute Bloom filters for changed paths diff: halt tree-diff early after max_changes bloom.c: core Bloom filter implementation for changed paths. bloom.c: introduce core Bloom filter constructs bloom.c: add the murmur3 hash implementation commit-graph: define and use MAX_NUM_CHUNKS
2020-05-01Merge branch 'jk/build-with-right-curl'Libravatar Junio C Hamano1-5/+10
The build procedure did not use the libcurl library and its include files correctly for a custom-built installation. * jk/build-with-right-curl: Makefile: avoid running curl-config unnecessarily Makefile: use curl-config --cflags Makefile: avoid running curl-config multiple times
2020-04-29Merge branch 'dl/merge-autostash'Libravatar Junio C Hamano1-38/+40
"git merge" learns the "--autostash" option. * dl/merge-autostash: (22 commits) pull: pass --autostash to merge t5520: make test_pull_autostash() accept expect_parent_num merge: teach --autostash option sequencer: implement apply_autostash_oid() sequencer: implement save_autostash() sequencer: unlink autostash in apply_autostash() sequencer: extract perform_autostash() from rebase rebase: generify create_autostash() rebase: extract create_autostash() reset: extract reset_head() from rebase rebase: generify reset_head() rebase: use apply_autostash() from sequencer.c sequencer: rename stash_sha1 to stash_oid sequencer: make apply_autostash() accept a path rebase: use read_oneliner() sequencer: make read_oneliner() extern sequencer: configurably warn on non-existent files sequencer: make read_oneliner() accept flags sequencer: make file exists check more efficient sequencer: stop leaking buf ...