summaryrefslogtreecommitdiff
path: root/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2019-03-20Merge branch 'ab/makefile-help-devs-more'Libravatar Junio C Hamano1-30/+33
CFLAGS now can be tweaked when invoking Make while using DEVELOPER=YesPlease; this did not work well before. * ab/makefile-help-devs-more: Makefile: allow for combining DEVELOPER=1 and CFLAGS="..." Makefile: move the setting of *FLAGS closer to "include" Makefile: Move *_LIBS assignment into its own section Makefile: add/remove comments at top and tweak whitespace Makefile: move "strip" assignment down from flags Makefile: remove an out-of-date comment
2019-03-11Merge branch 'js/find-lib-h-with-ls-files-when-possible'Libravatar Junio C Hamano1-2/+3
The Makefile uses 'find' utility to enumerate all the *.h header files, which is expensive on platforms with slow filesystems; it now optionally uses "ls-files" if working within a repository, which is a trick similar to how all sources are enumerated to run ETAGS on. * js/find-lib-h-with-ls-files-when-possible: Makefile: use `git ls-files` to list header files, if possible
2019-03-11Merge branch 'rj/hdr-check-gcrypt-fix'Libravatar Junio C Hamano1-1/+4
The set of header files used by "make hdr-check" unconditionally included sha256/gcrypt.h, even when it is not used, causing the make target to fail. We now skip it when GCRYPT_SHA256 is not in use. * rj/hdr-check-gcrypt-fix: Makefile: fix 'hdr-check' when GCRYPT not installed
2019-03-06Makefile: fix 'hdr-check' when GCRYPT not installedLibravatar Ramsay Jones1-1/+4
If the GCRYPT_SHA256 build variable is not set, then the 'hdr-check' target complains about the missing <gcrypt.h> header file. Add the 'sha256/gcrypt.h' header file to the exception list, if the build variable is not defined. While here, replace the 'xdiff%' filter pattern with 'xdiff/%' (and similarly for the compat pattern) since the original pattern inadvertently excluded the 'xdiff-interface.h' header. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-05Makefile: use `git ls-files` to list header files, if possibleLibravatar Johannes Schindelin1-2/+3
In d85b0dff72 (Makefile: use `find` to determine static header dependencies, 2014-08-25), we switched from a static list of header files to a dynamically-generated one, asking `find` to enumerate them. Back in those days, we did not use `$(LIB_H)` by default, and many a `make` implementation seems smart enough not to run that `find` command in that case, so it was deemed okay to run `find` for special targets requiring this macro. However, as of ebb7baf02f (Makefile: add a hdr-check target, 2018-09-19), $(LIB_H) is part of a global rule and therefore must be expanded. Meaning: this `find` command has to be run upon every `make` invocation. In the presence of many a worktree, this can tax the developers' patience quite a bit. Even in the absence of worktrees or other untracked files and directories, the cost of I/O to generate that list of header files is simply a lot larger than a simple `git ls-files` call. Therefore, just like in 335339758c (Makefile: ask "ls-files" to list source files if available, 2011-10-18), we now prefer to use `git ls-files` to enumerate the header files to enumerating them via `find`, falling back to the latter if the former failed (which would be the case e.g. in a worktree that was extracted from a source .tar file rather than from a clone of Git's sources). This has one notable consequence: we no longer include `command-list.h` in `LIB_H`, as it is a generated file, not a tracked one, but that is easily worked around. Of the three sites that use `LIB_H`, two (`LOCALIZED_C` and `CHK_HDRS`) already handle generated headers separately. In the third, the computed-dependency fallback, we can just add in a reference to $(GENERATED_H). Likewise, we no longer include not-yet-tracked header files in `LIB_H`. Given the speed improvements, these consequences seem a comparably small price to pay. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Acked-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-24Makefile: allow for combining DEVELOPER=1 and CFLAGS="..."Libravatar Ævar Arnfjörð Bjarmason1-2/+6
Ever since the DEVELOPER=1 facility introduced there's been no way to have custom CFLAGS (e.g. CFLAGS="-O0 -g -ggdb3") while still benefiting from the set of warnings and assertions DEVELOPER=1 enables. This is because the semantics of variables in the Makefile are such that the user setting CFLAGS overrides anything we set, including what we're doing in config.mak.dev[1]. So let's introduce a "DEVELOPER_CFLAGS" variable in config.mak.dev and add it to ALL_CFLAGS. Before this the ALL_CFLAGS variable would (basically, there's some nuance we won't go into) be set to: $(CPPFLAGS) [$(CFLAGS) *or* $(CFLAGS) in config.mak.dev] $(BASIC_CFLAGS) $(EXTRA_CPPFLAGS) But will now be: $(DEVELOPER_CFLAGS) $(CPPFLAGS) $(CFLAGS) $(BASIC_CFLAGS) $(EXTRA_CPPFLAGS) The reason for putting DEVELOPER_CFLAGS first is to allow for selectively overriding something DEVELOPER=1 brings in. On both GCC and Clang later settings override earlier ones. E.g. "-Wextra -Wno-extra" will enable no "extra" warnings, but not if those two arguments are reversed. Examples of things that weren't possible before, but are now: # Use -O0 instead of -O2 for less painful debuggng DEVELOPER=1 CFLAGS="-O0 -g" # DEVELOPER=1 plus -Wextra, but disable some of the warnings DEVELOPER=1 DEVOPTS="no-error extra-all" CFLAGS="-O0 -g -Wno-unused-parameter" The reason for the patches leading up to this one re-arranged the various *FLAGS assignments and includes is just for readability. The Makefile supports assignments out of order, e.g.: $ cat Makefile X = $(A) $(B) $(C) A = A B = B include c.mak all: @echo $(X) $ cat c.mak C=C $ make A B C So we could have gotten away with the much smaller change of changing "CFLAGS" in config.mak.dev to "DEVELOPER_CFLAGS" and adding that to ALL_CFLAGS earlier in the Makefile "before" the config.mak.* includes. But I think it's more readable to use variables "after" they're included. 1. https://www.gnu.org/software/make/manual/html_node/Overriding.html Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-24Makefile: move the setting of *FLAGS closer to "include"Libravatar Ævar Arnfjörð Bjarmason1-18/+22
Move the setting of variables like CFLAGS down past settings like "prefix" and default programs like "TAR" to just before we do the include from "config.mak.*". There's no functional changes here yet, but move note that "ALL_CFLAGS" and "ALL_LDFLAGS" are moved below the include. A follow-up change will tweak those depending on a variable set in config.mak.dev. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-24Makefile: Move *_LIBS assignment into its own sectionLibravatar Ævar Arnfjörð Bjarmason1-1/+3
Now the only other non-program assignment in the previous list is PTHREAD_CFLAGS, which'll be moved elsewhere in a follow-up change. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-24Makefile: add/remove comments at top and tweak whitespaceLibravatar Ævar Arnfjörð Bjarmason1-7/+3
The top of the Makfile is mostly separated into logical steps like set default configuration, set programs etc., but there's some deviation from that. Let's add mostly comments where they're missing, remove those that don't add anything. The whitespace tweaking makes subsequent patches smaller. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-24Makefile: move "strip" assignment down from flagsLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Move the assignment of the "STRIP" variable down to where we're setting variables with the names of other programs. For consistency with those use "=" for the assignment instead of "?=". I can't imagine why this would need to be different than the rest, and 4dc00021f7 ("Makefile: add 'strip' target", 2006-01-12) which added it doesn't provide an explanation. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-24Makefile: remove an out-of-date commentLibravatar Ævar Arnfjörð Bjarmason1-3/+0
Remove a comment referring to a caveat that hasn't been applicable since 18b0fc1ce1 ("Git.pm: Kill Git.xs for now", 2006-09-23). At the time of 8d7f586f13 ("Git.pm: Support for perl/ being built by a different compiler", 2006-06-25) some of the code in perl would be built by a C compiler, but support for that went away a few months later in 18b0fc1ce1 discussed above. Since my 20d2a30f8f ("Makefile: replace perl/Makefile.PL with simple make rules", 2017-12-10) the perl/ directory doesn't even have its own build process. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-22trace2: t/helper/test-trace2, t0210.sh, t0211.sh, t0212.shLibravatar Jeff Hostetler1-0/+1
Create unit tests for Trace2. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-22trace2: create new combined trace facilityLibravatar Jeff Hostetler1-1/+13
Create a new unified tracing facility for git. The eventual intent is to replace the current trace_printf* and trace_performance* routines with a unified set of git_trace2* routines. In addition to the usual printf-style API, trace2 provides higer-level event verbs with fixed-fields allowing structured data to be written. This makes post-processing and analysis easier for external tools. Trace2 defines 3 output targets. These are set using the environment variables "GIT_TR2", "GIT_TR2_PERF", and "GIT_TR2_EVENT". These may be set to "1" or to an absolute pathname (just like the current GIT_TRACE). * GIT_TR2 is intended to be a replacement for GIT_TRACE and logs command summary data. * GIT_TR2_PERF is intended as a replacement for GIT_TRACE_PERFORMANCE. It extends the output with columns for the command process, thread, repo, absolute and relative elapsed times. It reports events for child process start/stop, thread start/stop, and per-thread function nesting. * GIT_TR2_EVENT is a new structured format. It writes event data as a series of JSON records. Calls to trace2 functions log to any of the 3 output targets enabled without the need to call different trace_printf* or trace_performance* routines. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-19tests: teach the test-tool to generate NUL bytes and use itLibravatar Johannes Schindelin1-0/+1
In cc95bc2025 (t5562: replace /dev/zero with a pipe from generate_zero_bytes, 2019-02-09), we replaced usage of /dev/zero (which is not available on NonStop, apparently) by a Perl script snippet to generate NUL bytes. Sadly, it does not seem to work on NonStop, as t5562 reportedly hangs. Worse, this also hangs in the Ubuntu 16.04 agents of the CI builds on Azure Pipelines: for some reason, the Perl script snippet that is run via `generate_zero_bytes` in t5562's 'CONTENT_LENGTH overflow ssite_t' test case tries to write out an infinite amount of NUL bytes unless a broken pipe is encountered, that snippet never encounters the broken pipe, and keeps going until the build times out. Oddly enough, this does not reproduce on the Windows and macOS agents, nor in a local Ubuntu 18.04. This developer tried for a day to figure out the exact circumstances under which this hang happens, to no avail, the details remain a mystery. In the end, though, what counts is that this here change incidentally fixes that hang (maybe also on NonStop?). Even more positively, it gets rid of yet another unnecessary Perl invocation. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-13Merge branch 'bc/utf16-portability-fix'Libravatar Junio C Hamano1-0/+7
The code and tests assume that the system supplied iconv() would always use BOM in its output when asked to encode to UTF-16 (or UTF-32), but apparently some implementations output big-endian without BOM. A compile-time knob has been added to help such systems (e.g. NonStop) to add BOM to the output to increase portability. * bc/utf16-portability-fix: utf8: handle systems that don't write BOM for UTF-16
2019-02-13Merge branch 'nd/fileno-may-be-macro'Libravatar Junio C Hamano1-0/+7
* nd/fileno-may-be-macro: git-compat-util: work around fileno(fp) that is a macro
2019-02-12git-compat-util: work around fileno(fp) that is a macroLibravatar Duy Nguyen1-0/+7
On various BSD's, fileno(fp) is implemented as a macro that directly accesses the fields in the FILE * object, which breaks a function that accepts a "void *fp" parameter and calls fileno(fp) and expect it to work. Work it around by adding a compile-time knob FILENO_IS_A_MACRO that inserts a real helper function in the middle of the callchain. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-11utf8: handle systems that don't write BOM for UTF-16Libravatar brian m. carlson1-0/+7
When serializing UTF-16 (and UTF-32), there are three possible ways to write the stream. One can write the data with a BOM in either big-endian or little-endian format, or one can write the data without a BOM in big-endian format. Most systems' iconv implementations choose to write it with a BOM in some endianness, since this is the most foolproof, and it is resistant to misinterpretation on Windows, where UTF-16 and the little-endian serialization are very common. For compatibility with Windows and to avoid accidental misuse there, Git always wants to write UTF-16 with a BOM, and will refuse to read UTF-16 without it. However, musl's iconv implementation writes UTF-16 without a BOM, relying on the user to interpret it as big-endian. This causes t0028 and the related functionality to fail, since Git won't read the file without a BOM. Add a Makefile and #define knob, ICONV_OMITS_BOM, that can be set if the iconv implementation has this behavior. When set, Git will write a BOM manually for UTF-16 and UTF-32 and then force the data to be written in UTF-16BE or UTF-32BE. We choose big-endian behavior here because the tests use the raw "UTF-16" encoding, which will be big-endian when the implementation requires this knob to be set. Update the tests to detect this case and write test data with an added BOM if necessary. Always write the BOM in the tests in big-endian format, since all iconv implementations that omit a BOM must use big-endian serialization according to the Unicode standard. Preserve the existing behavior for systems which do not have this knob enabled, since they may use optimized implementations, including defaulting to the native endianness, which may improve performance. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-08Merge branch 'ds/coverage-prove'Libravatar Junio C Hamano1-0/+5
A new target "coverage-prove" to run the coverage test under "prove" has been added. * ds/coverage-prove: Makefile: add coverage-prove target
2019-02-06Merge branch 'rj/sparse-flags'Libravatar Junio C Hamano1-5/+9
Use of the sparse tool got easier to customize from the command line to help developers. * rj/sparse-flags: Makefile: improve SPARSE_FLAGS customisation config.mak.uname: remove obsolete SPARSE_FLAGS setting
2019-02-06Merge branch 'js/vsts-ci'Libravatar Junio C Hamano1-0/+11
Prepare to run test suite on Azure Pipeline. * js/vsts-ci: (22 commits) test-date: drop unused parameter to getnanos() ci: parallelize testing on Windows ci: speed up Windows phase tests: optionally skip bin-wrappers/ t0061: workaround issues with --with-dashes and RUNTIME_PREFIX tests: add t/helper/ to the PATH with --with-dashes mingw: try to work around issues with the test cleanup tests: include detailed trace logs with --write-junit-xml upon failure tests: avoid calling Perl just to determine file sizes README: add a build badge (status of the Azure Pipelines build) mingw: be more generous when wrapping up the setitimer() emulation ci: use git-sdk-64-minimal build artifact ci: add a Windows job to the Azure Pipelines definition Add a build definition for Azure DevOps ci/lib.sh: add support for Azure Pipelines tests: optionally write results as JUnit-style .xml test-date: add a subcommand to measure times in shell scripts ci: use a junction on Windows instead of a symlink ci: inherit --jobs via MAKEFLAGS in run-build-and-tests ci/lib.sh: encapsulate Travis-specific things ...
2019-02-06Merge branch 'en/rebase-merge-on-sequencer'Libravatar Junio C Hamano1-1/+0
"git rebase --merge" as been reimplemented by reusing the internal machinery used for "git rebase -i". * en/rebase-merge-on-sequencer: rebase: implement --merge via the interactive machinery rebase: define linearization ordering and enforce it git-legacy-rebase: simplify unnecessary triply-nested if git-rebase, sequencer: extend --quiet option for the interactive machinery am, rebase--merge: do not overlook --skip'ed commits with post-rewrite t5407: add a test demonstrating how interactive handles --skip differently rebase: fix incompatible options error message rebase: make builtin and legacy script error messages the same
2019-02-05Merge branch 'js/commit-graph-chunk-table-fix'Libravatar Junio C Hamano1-1/+2
The codepath to read from the commit-graph file attempted to read past the end of it when the file's table-of-contents was corrupt. * js/commit-graph-chunk-table-fix: Makefile: correct example fuzz build commit-graph: fix buffer read-overflow commit-graph, fuzz: add fuzzer for commit-graph
2019-02-05Makefile: improve SPARSE_FLAGS customisationLibravatar Ramsay Jones1-5/+9
In order to enable greater user customisation of the SPARSE_FLAGS variable, we introduce a new SP_EXTRA_FLAGS variable to use for target specific settings. Without using the new variable, setting the SPARSE_FLAGS on the 'make' command-line would also override the value set by the target-specific rules in the Makefile (effectively making them useless). Also, this enables the SP_EXTRA_FLAGS to be used in the future for any other internal customisations, such as for some platform specific values. In addition, we initialise the SPARSE_FLAGS to the default (empty) value using a conditional assignment (?=). This allows SPARSE_FLAGS to be set from the environment as well as from the command-line. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-29Merge branch 'bc/sha-256'Libravatar Junio C Hamano1-0/+22
Add sha-256 hash and plug it through the code to allow building Git with the "NewHash". * bc/sha-256: hash: add an SHA-256 implementation using OpenSSL sha256: add an SHA-256 implementation using libgcrypt Add a base implementation of SHA-256 support commit-graph: convert to using the_hash_algo t/helper: add a test helper to compute hash speed sha1-file: add a constant for hash block size t: make the sha1 test-tool helper generic t: add basic tests for our SHA-1 implementation cache: make hashcmp and hasheq work with larger hashes hex: introduce functions to print arbitrary hashes sha1-file: provide functions to look up hash algorithms sha1-file: rename algorithm to "sha1"
2019-01-29Makefile: add coverage-prove targetLibravatar Derrick Stolee1-0/+5
Sometimes there are test failures in the 'pu' branch. This is somewhat expected for a branch that takes the very latest topics under development, and those sometimes have semantic conflicts that only show up during test runs. This also can happen when running the test suite with different GIT_TEST_* environment variables that interact in unexpected ways This causes a problem for the test coverage reports, as the typical 'make coverage-test coverage-report' run halts at the first failed test. If that test is early in the suite, then many valuable tests are not exercising the code and the coverage report becomes noisy with false positives. Add a new 'coverage-prove' target to the Makefile, modeled after the 'coverage-test' target. This compiles the source using the coverage flags, then runs the test suite using the 'prove' tool. Since the coverage machinery is not thread-safe, enforce that the tests are run in sequence by appending '-j1' to GIT_PROVE_OPTS. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-29ci: parallelize testing on WindowsLibravatar Johannes Schindelin1-0/+10
The fact that Git's test suite is implemented in Unix shell script that is as portable as we can muster, combined with the fact that Unix shell scripting is foreign to Windows (and therefore has to be emulated), results in pretty abysmal speed of the test suite on that platform, for pretty much no other reason than that language choice. For comparison: while the Linux build & test is typically done within about 8 minutes, the Windows build & test typically lasts about 80 minutes in Azure Pipelines. To help with that, let's use the Azure Pipeline feature where you can parallelize jobs, make jobs depend on each other, and pass artifacts between them. The tests are distributed using the following heuristic: listing all test scripts ordered by size in descending order (as a cheap way to estimate the overall run time), every Nth script is run (where N is the total number of parallel jobs), starting at the index corresponding to the parallel job. This slicing is performed by a new function that is added to the `test-tool`. To optimize the overall runtime of the entire Pipeline, we need to move the Windows jobs to the beginning (otherwise there would be a very decent chance for the Pipeline to be run only the Windows build, while all the parallel Windows test jobs wait for this single one). We use Azure Pipelines Artifacts for both the minimal Git for Windows SDK as well as the built executables, as deduplication and caching close to the agents makes that really fast. For comparison: while downloading and unpacking the minimal Git for Windows SDK via PowerShell takes only one minute (down from anywhere between 2.5 to 7 when using a shallow clone), uploading it as Pipeline Artifact takes less than 30s and downloading and unpacking less than 20s (sometimes even as little as only twelve seconds). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-29tests: optionally write results as JUnit-style .xmlLibravatar Johannes Schindelin1-0/+1
This will come in handy when publishing the results of Git's test suite during an automated Azure DevOps run. Note: we need to make extra sure that invalid UTF-8 encoding is turned into valid UTF-8 (using the Replacement Character, \uFFFD) because t9902's trace contains such invalid byte sequences, and the task in the Azure Pipeline that uploads the test results would refuse to do anything if it was asked to parse an .xml file with invalid UTF-8 in it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-15Makefile: correct example fuzz buildLibravatar Josh Steadmon1-1/+1
The comment explaining how to build the fuzzers was broken in 927c77e7d4d ("Makefile: use FUZZ_CXXFLAGS for linking fuzzers", 2018-11-14). When building fuzzers, all .c files must be compiled with coverage tracing enabled. This is not possible when using only FUZZ_CXXFLAGS, as that flag is only applied to the fuzzers themselves. Switching back to CFLAGS fixes the issue. Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-15commit-graph, fuzz: add fuzzer for commit-graphLibravatar Josh Steadmon1-0/+1
Break load_commit_graph_one() into a new function, parse_commit_graph(). The latter function operates on arbitrary buffers, which makes it suitable as a fuzzing target. Since parse_commit_graph() is only called by load_commit_graph_one() (and the fuzzer described below), we omit error messages that would be duplicated by the caller. Adds fuzz-commit-graph.c, which provides a fuzzing entry point compatible with libFuzzer (and possibly other fuzzing engines). Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-07rebase: implement --merge via the interactive machineryLibravatar Elijah Newren1-1/+0
As part of an ongoing effort to make rebase have more uniform behavior, modify the merge backend to behave like the interactive one, by re-implementing it on top of the latter. Interactive rebases are implemented in terms of cherry-pick rather than the merge-recursive builtin, but cherry-pick also calls into the recursive merge machinery by default and can accept special merge strategies and/or special strategy options. As such, there really is not any need for having both git-rebase--merge and git-rebase--interactive anymore. Delete git-rebase--merge.sh and instead implement it in builtin/rebase.c. This results in a few deliberate but small user-visible changes: * The progress output is modified (see t3406 and t3420 for examples) * A few known test failures are now fixed (see t3421) * bash-prompt during a rebase --merge is now REBASE-i instead of REBASE-m. Reason: The prompt is a reflection of the backend in use; this allows users to report an issue to the git mailing list with the appropriate backend information, and allows advanced users to know where to search for relevant control files. (see t9903) testcase modification notes: t3406: --interactive and --merge had slightly different progress output while running; adjust a test to match the new expectation t3420: these test precise output while running, but rebase--am, rebase--merge, and rebase--interactive all were built on very different commands (am, merge-recursive, cherry-pick), so the tests expected different output for each type. Now we expect --merge and --interactive to have the same output. t3421: --interactive fixes some bugs in --merge! Wahoo! t9903: --merge uses the interactive backend so the prompt expected is now REBASE-i. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-19Merge branch 'sb/cocci-pending'Libravatar Junio C Hamano1-2/+5
A coding convention around the Coccinelle semantic patches to have two classes to ease code migration process has been proposed and its support has been added to the Makefile. * sb/cocci-pending: coccicheck: introduce 'pending' semantic patches
2018-11-19Merge branch 'js/test-git-installed'Libravatar Junio C Hamano1-0/+1
Update the "test installed Git" mode of our test suite to work better. * js/test-git-installed: tests: explicitly use `git.exe` on Windows tests: do not require Git to be built when testing an installed Git t/lib-gettext: test installed git-sh-i18n if GIT_TEST_INSTALLED is set tests: respect GIT_TEST_INSTALLED when initializing repositories tests: fix GIT_TEST_INSTALLED's PATH to include t/helper/
2018-11-19Merge branch 'dd/poll-dot-h'Libravatar Junio C Hamano1-1/+7
A build update. * dd/poll-dot-h: git-compat-util: prefer poll.h to sys/poll.h
2018-11-19Merge branch 'ab/dynamic-gettext-poison'Libravatar Junio C Hamano1-7/+1
Our testing framework uses a special i18n "poisoned localization" feature to find messages that ought to stay constant but are incorrectly marked to be translated. This feature has been made into a runtime option (it used to be a compile-time option). * ab/dynamic-gettext-poison: Makefile: ease dynamic-gettext-poison transition i18n: make GETTEXT_POISON a runtime option
2018-11-18Merge branch 'js/fuzz-cxxflags'Libravatar Junio C Hamano1-2/+4
The build procedure to link for fuzzing test has been made customizable with a new Makefile variable. * js/fuzz-cxxflags: Makefile: use FUZZ_CXXFLAGS for linking fuzzers
2018-11-18Merge branch 'js/mingw-res-rebuild'Libravatar Junio C Hamano1-1/+1
Windows build update. * js/mingw-res-rebuild: Windows: force-recompile git.res for differing architectures
2018-11-18Merge branch 'jk/curl-ldflags'Libravatar Junio C Hamano1-15/+15
The way -lcurl library gets linked has been simplified by taking advantage of the fact that we can just ask curl-config command how. * jk/curl-ldflags: build: link with curl-defined linker flags
2018-11-18Merge branch 'nd/pthreads'Libravatar Junio C Hamano1-1/+1
The codebase has been cleaned up to reduce "#ifndef NO_PTHREADS". * nd/pthreads: Clean up pthread_create() error handling read-cache.c: initialize copy_len to shut up gcc 8 read-cache.c: reduce branching based on HAVE_THREADS read-cache.c: remove #ifdef NO_PTHREADS pack-objects: remove #ifdef NO_PTHREADS preload-index.c: remove #ifdef NO_PTHREADS grep: clean up num_threads handling grep: remove #ifdef NO_PTHREADS attr.c: remove #ifdef NO_PTHREADS name-hash.c: remove #ifdef NO_PTHREADS index-pack: remove #ifdef NO_PTHREADS send-pack.c: move async's #ifdef NO_PTHREADS back to run-command.c run-command.h: include thread-utils.h instead of pthread.h thread-utils: macros to unconditionally compile pthreads API
2018-11-16Makefile: use FUZZ_CXXFLAGS for linking fuzzersLibravatar Josh Steadmon1-2/+4
OSS-Fuzz requires C++-specific flags to link fuzzers. Passing these in CFLAGS causes lots of build warnings. Using separate FUZZ_CXXFLAGS avoids this. Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16tests: explicitly use `git.exe` on WindowsLibravatar Johannes Schindelin1-0/+1
On Windows, when we refer to `/an/absolute/path/to/git`, it magically resolves `git.exe` at that location. Except if something of the name `git` exists next to that `git.exe`. So if we call `$BUILD_DIR/git`, it will find `$BUILD_DIR/git.exe` *only* if there is not, say, a directory called `$BUILD_DIR/git`. Such a directory, however, exists in Git for Windows when building with Visual Studio (our Visual Studio project generator defaults to putting the build files into a directory whose name is the base name of the corresponding `.exe`). In the bin-wrappers/* scripts, we already take pains to use `git.exe` rather than `git`, as this could pick up the wrong thing on Windows (i.e. if there exists a `git` file or directory in the build directory). Now we do the same in the tests' start-up code. This also helps when testing an installed Git, as there might be even more likely some stray file or directory in the way. Note: the only way we can record whether the `.exe` suffix is by writing it to the `GIT-BUILD-OPTIONS` file and sourcing it at the beginning of `t/test-lib.sh`. This is not a requirement introduced by this patch, but we move the call to be able to use the `$X` variable that holds the file extension, if any. Note also: the many, many calls to `git this` and `git that` are unaffected, as the regular PATH search will find the `.exe` files on Windows (and not be confused by a directory of the name `git` that is in one of the directories listed in the `PATH` variable), while `/path/to/git` would not, per se, know that it is looking for an executable and happily prefer such a directory. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14hash: add an SHA-256 implementation using OpenSSLLibravatar brian m. carlson1-0/+7
We already have OpenSSL routines available for SHA-1, so add routines for SHA-256 as well. On a Core i7-6600U, this SHA-256 implementation compares favorably to the SHA1DC SHA-1 implementation: SHA-1: 157 MiB/s (64 byte chunks); 337 MiB/s (16 KiB chunks) SHA-256: 165 MiB/s (64 byte chunks); 408 MiB/s (16 KiB chunks) Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14sha256: add an SHA-256 implementation using libgcryptLibravatar brian m. carlson1-2/+11
Generally, one gets better performance out of cryptographic routines written in assembly than C, and this is also true for SHA-256. In addition, most Linux distributions cannot distribute Git linked against OpenSSL for licensing reasons. Most systems with GnuPG will also have libgcrypt, since it is a dependency of GnuPG. libgcrypt is also faster than the SHA1DC implementation for messages of a few KiB and larger. For comparison, on a Core i7-6600U, this implementation processes 16 KiB chunks at 355 MiB/s while SHA1DC processes equivalent chunks at 337 MiB/s. In addition, libgcrypt is licensed under the LGPL 2.1, which is compatible with the GPL. Add an implementation of SHA-256 that uses libgcrypt. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14Add a base implementation of SHA-256 supportLibravatar brian m. carlson1-0/+4
SHA-1 is weak and we need to transition to a new hash function. For some time, we have referred to this new function as NewHash. Recently, we decided to pick SHA-256 as NewHash. The reasons behind the choice of SHA-256 are outlined in the thread starting at [1] and in the commit history for the hash function transition document. Add a basic implementation of SHA-256 based off libtomcrypt, which is in the public domain. Optimize it and restructure it to meet our coding standards. Pull in the update and final functions from the SHA-1 block implementation, as we know these function correctly with all compilers. This implementation is slower than SHA-1, but more performant implementations will be introduced in future commits. Wire up SHA-256 in the list of hash algorithms, and add a test that the algorithm works correctly. Note that with this patch, it is still not possible to switch to using SHA-256 in Git. Additional patches are needed to prepare the code to handle a larger hash algorithm and further test fixes are needed. [1] https://public-inbox.org/git/20180609224913.GC38834@genre.crustytoothpaste.net/ Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14t/helper: add a test helper to compute hash speedLibravatar brian m. carlson1-0/+1
Add a utility (which is less for the testsuite and more for developers) that can compute hash speeds for whatever hash algorithms are implemented. This allows developers to test their personal systems to determine the performance characteristics of various algorithms. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14t: make the sha1 test-tool helper genericLibravatar brian m. carlson1-0/+1
Since we're going to have multiple hash algorithms to test, it makes sense to share as much of the test code as possible. Convert the sha1 helper for the test-tool to be generic and move it out into its own module. This will allow us to share most of this code with our NewHash implementation. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14git-compat-util: prefer poll.h to sys/poll.hLibravatar Đoàn Trần Công Danh1-1/+7
POSIX specifies that <poll.h> is the correct header for poll(2) whereas <sys/poll.h> is only needed for some old libc. Let's follow the POSIX way by default. This effectively eliminates musl's warning: warning redirecting incorrect #include <sys/poll.h> to <poll.h> Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-14coccicheck: introduce 'pending' semantic patchesLibravatar SZEDER Gábor1-2/+5
Teach `make coccicheck` to avoid patches named "*.pending.cocci" and handle them separately in a new `make coccicheck-pending` instead. This means that we can separate "critical" patches from "FYI" patches. The former target can continue causing Travis to fail its static analysis job, while the latter can let us keep an eye on ongoing (pending) transitions without them causing too much fallout. Document the intended use-cases around these two targets. As the process around the pending patches is not yet fully explored, leave that out. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Based-on-work-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-13Merge branch 'ao/submodule-wo-gitmodules-checked-out'Libravatar Junio C Hamano1-0/+1
The submodule support has been updated to read from the blob at HEAD:.gitmodules when the .gitmodules file is missing from the working tree. * ao/submodule-wo-gitmodules-checked-out: t/helper: add test-submodule-nested-repo-config submodule: support reading .gitmodules when it's not in the working tree submodule: add a helper to check if it is safe to write to .gitmodules t7506: clean up .gitmodules properly before setting up new scenario submodule: use the 'submodule--helper config' command submodule--helper: add a new 'config' subcommand t7411: be nicer to future tests and really clean things up t7411: merge tests 5 and 6 submodule: factor out a config_set_in_gitmodules_file_gently function submodule: add a print_config_from_gitmodules() helper
2018-11-13Merge branch 'nd/config-split'Libravatar Junio C Hamano1-1/+1
Split the overly large Documentation/config.txt file into million little pieces. This potentially allows each individual piece included into the manual page of the command it affects more easily. * nd/config-split: (81 commits) config.txt: remove config/dummy.txt config.txt: move worktree.* to a separate file config.txt: move web.* to a separate file config.txt: move versionsort.* to a separate file config.txt: move user.* to a separate file config.txt: move url.* to a separate file config.txt: move uploadpack.* to a separate file config.txt: move uploadarchive.* to a separate file config.txt: move transfer.* to a separate file config.txt: move tag.* to a separate file config.txt: move submodule.* to a separate file config.txt: move stash.* to a separate file config.txt: move status.* to a separate file config.txt: move splitIndex.* to a separate file config.txt: move showBranch.* to a separate file config.txt: move sequencer.* to a separate file config.txt: move sendemail-config.txt to config/ config.txt: move reset.* to a separate file config.txt: move rerere.* to a separate file config.txt: move repack.* to a separate file ...