summaryrefslogtreecommitdiff
path: root/t/test-lib.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-08-20Merge branch 'wc/make-funnynames-shared-lazy-prereq'Libravatar Junio C Hamano1-0/+14
A test prerequisite defined by various test scripts with slightly different semantics has been consolidated into a single copy and made into a lazily defined one. * wc/make-funnynames-shared-lazy-prereq: t: factor out FUNNYNAMES as shared lazy prereq
2018-08-06t: factor out FUNNYNAMES as shared lazy prereqLibravatar William Chargin1-0/+14
A fair number of tests need to check that the filesystem supports file names including "funny" characters, like newline, tab, and double-quote. Jonathan Nieder suggested that this be extracted into a lazy prereq in the top-level `test-lib.sh`. This patch effects that change. The FUNNYNAMES prereq now uniformly requires support for newlines, tabs, and double-quotes in filenames. This very slightly decreases the power of some tests, which might have run previously on a system that supports (e.g.) newlines and tabs but not double-quotes, but now will not. This seems to me like an acceptable tradeoff for consistency. One test (`t/t9902-completion.sh`) defined FUNNYNAMES to further require the separators \034 through \037, the test for which was implemented using the Bash-specific $'\034' syntax. I've elected to leave this one as is, renaming it to FUNNIERNAMES. After this patch, `git grep 'test_\(set\|lazy\)_prereq.*FUNNYNAMES'` has only one result. Signed-off-by: William Chargin <wchargin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-17t/test-lib: teach --chain-lint to detect broken &&-chains in subshellsLibravatar Eric Sunshine1-1/+2
The --chain-lint option detects broken &&-chains by forcing the test to exit early (as the very first step) with a sentinel value. If that sentinel is the test's overall exit code, then the &&-chain is intact; if not, then the chain is broken. Unfortunately, this detection does not extend to &&-chains within subshells even when the subshell itself is properly linked into the outer &&-chain. Address this shortcoming by feeding the body of the test to a lightweight "linter" which can peer inside subshells and identify broken &&-chains by pure textual inspection. Although the linter does not actually parse shell scripts, it has enough knowledge of shell syntax to reliably deal with formatting style variations (as evolved over the years) and to avoid being fooled by non-shell content (such as inside here-docs and multi-line strings). It recognizes modern subshell formatting: statement1 && ( statement2 && statement3 ) && statement4 as well as old-style: statement1 && (statement2 && statement3) && statement4 Heuristics are employed to properly identify the extent of a subshell formatted in the old-style since a number of legitimate constructs may superficially appear to close the subshell even though they don't. For example, it understands that neither "x=$(command)" nor "case $x in *)" end a subshell, despite the ")" at the end of line. Due to limitations of the tool used ('sed') and its inherent line-by-line processing, only subshells one level deep are handled, as well as one-liner subshells one level below that. Subshells deeper than that or multi-line subshells at level two are passed through as-is, thus &&-chains in their bodies are not checked. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-30Merge branch 'bc/hash-independent-tests'Libravatar Junio C Hamano1-1/+10
Many tests hardcode the raw object names, which would change once we migrate away from SHA-1. While some of them must test against exact object names, most of them do not have to use hardcoded constants in the test. The latter kind of tests have been updated to test the moral equivalent of the original without hardcoding the actual object names. * bc/hash-independent-tests: (28 commits) t5300: abstract away SHA-1-specific constants t4208: abstract away SHA-1-specific constants t4045: abstract away SHA-1-specific constants t4042: abstract away SHA-1-specific constants t4205: sort log output in a hash-independent way t/lib-diff-alternative: abstract away SHA-1-specific constants t4030: abstract away SHA-1-specific constants t4029: abstract away SHA-1-specific constants t4029: fix test indentation t4022: abstract away SHA-1-specific constants t4020: abstract away SHA-1-specific constants t4014: abstract away SHA-1-specific constants t4008: abstract away SHA-1-specific constants t4007: abstract away SHA-1-specific constants t3905: abstract away SHA-1-specific constants t3702: abstract away SHA-1-specific constants t3103: abstract away SHA-1-specific constants t2203: abstract away SHA-1-specific constants t: skip pack tests if not using SHA-1 t4044: skip test if not using SHA-1 ...
2018-05-23Merge branch 'tb/test-apfs-utf8-normalization'Libravatar Junio C Hamano1-6/+1
A test to see if the filesystem normalizes UTF-8 filename has been updated to check what we need to know in a more direct way, i.e. a path created in NFC form can be accessed with NFD form (or vice versa) to cope with APFS as well as HFS. * tb/test-apfs-utf8-normalization: test: correct detection of UTF8_NFD_TO_NFC for APFS
2018-05-14t/test-lib: introduce OID_REGEXLibravatar brian m. carlson1-1/+2
Currently we have a variable, $_x40, which contains a regex that matches a full 40-character hex constant. However, with NewHash, we'll have object IDs that are longer than 40 characters. In such a case, $_x40 will be a confusing name. Create a $OID_REGEX variable which will always reflect a regex matching the appropriate object ID, regardless of the length of the current hash. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-14t/test-lib: introduce ZERO_OIDLibravatar brian m. carlson1-1/+2
Currently we have a variable, $_z40, which contains the all-zero object ID. However, with NewHash, we'll have an all-zero object ID which is longer than 40 hex characters. In such a case, $_z40 will be a confusing name. Create a $ZERO_OID variable which will always reflect the all-zeros object ID, regardless of the length of the current hash. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-14t/test-lib: add an SHA1 prerequisiteLibravatar brian m. carlson1-0/+7
There are some basic tests in our codebase that test that we get fixed SHA-1 values. These are valuable because they make sure that our SHA-1 implementation is free of bugs, but obviously these tests will fail with a different hash. There are also tests which intentionally produce objects that have collisions when truncated to a certain length to test our handling of these cases. These tests, too, will fail with a different hash. Add an SHA1 prerequisite to annotate both of these types of tests and disable them when we're using a different hash. In the future, we will create versions of these tests which handle both SHA-1 and NewHash. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-02test: correct detection of UTF8_NFD_TO_NFC for APFSLibravatar Torsten Bögershausen1-6/+1
On HFS (which is the default Mac filesystem prior to High Sierra), unicode names are "decomposed" before recording. On APFS, which appears to be the new default filesystem in Mac OS High Sierra, filenames are recorded as specified by the user. APFS continues to allow the user to access it via any name that normalizes to the same thing. This difference causes t0050-filesystem.sh to fail two tests. Improve the test for a NFD/NFC in test-lib.sh: Test if the same file can be reached in pre- and decomposed unicode. Reported-By: Elijah Newren <newren@gmail.com> Signed-off-by: Torsten Bögershausen <tboegi@web.de> Tested-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-25Merge branch 'jk/t5561-missing-curl'Libravatar Junio C Hamano1-0/+4
Test fixes. * jk/t5561-missing-curl: t5561: skip tests if curl is not available t5561: drop curl stderr redirects
2018-04-05t5561: skip tests if curl is not availableLibravatar Jeff King1-0/+4
It's possible to have libcurl installed but not the curl command-line utility. The latter is not generally needed for Git's http support, but we use it in t5561 for basic tests of http-backend's functionality. Let's detect when it's missing and skip this test. Note that we can't mark the individual tests with the CURL prerequisite. They're in a shared t556x_common that uses the GET and POST functions as a level of indirection, and it's only our implementations of those functions in t5561 that requires curl. It's not a problem, though, as literally every test in the script would depend on the prerequisite anyway. Reported-by: Jens Krüger <Jens.Krueger@frm2.tum.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-27t/helper: merge test-date into test-toolLibravatar Nguyễn Thái Ngọc Duy1-2/+2
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-27t/helper: merge test-chmtime into test-toolLibravatar Nguyễn Thái Ngọc Duy1-3/+3
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-22Merge branch 'gs/test-unset-xdg-cache-home' into maintLibravatar Junio C Hamano1-0/+1
Test update. * gs/test-unset-xdg-cache-home: test-lib.sh: unset XDG_CACHE_HOME
2018-03-14Merge branch 'sg/test-x'Libravatar Junio C Hamano1-1/+18
Running test scripts under -x option of the shell is often not a useful way to debug them, because the error messages from the commands tests try to capture and inspect are contaminated by the tracing output by the shell. An earlier work done to make it more pleasant to run tests under -x with recent versions of bash is extended to cover posix shells that do not support BASH_XTRACEFD. * sg/test-x: travis-ci: run tests with '-x' tracing t/README: add a note about don't saving stderr of compound commands t1510-repo-setup: mark as untraceable with '-x' t9903-bash-prompt: don't check the stderr of __git_ps1() t5570-git-daemon: don't check the stderr of a subshell t5526: use $TRASH_DIRECTORY to specify the path of GIT_TRACE log file t5500-fetch-pack: don't check the stderr of a subshell t3030-merge-recursive: don't check the stderr of a subshell t1507-rev-parse-upstream: don't check the stderr of a shell function t: add means to disable '-x' tracing for individual test scripts t: prevent '-x' tracing from interfering with test helpers' stderr
2018-02-28Merge branch 'gs/test-unset-xdg-cache-home'Libravatar Junio C Hamano1-0/+1
Test update. * gs/test-unset-xdg-cache-home: test-lib.sh: unset XDG_CACHE_HOME
2018-02-27t: add means to disable '-x' tracing for individual test scriptsLibravatar SZEDER Gábor1-1/+18
The previous patch resolved most of the test failures caused by running our test suite with '-x' tracing and /bin/sh, and the following patches in this series will resolve almost all of the remaining failures. Unfortunately, not yet all. Add means to disable '-x' tracing for individual test scripts by setting the $test_untraceable variable to a non-empty value in the test script before sourcing 'test-lib.sh'. However, since '-x' tracing is not an issue with recent Bash versions supporting BASH_XTRACEFD, i.e. v4.1 and later, don't disable tracing when the test script is run with such a Bash version even when $test_untraceable is set. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-21Merge branch 'sg/test-i18ngrep'Libravatar Junio C Hamano1-26/+0
Test fixes. * sg/test-i18ngrep: t: make 'test_i18ngrep' more informative on failure t: validate 'test_i18ngrep's parameters t: move 'test_i18ncmp' and 'test_i18ngrep' to 'test-lib-functions.sh' t5536: let 'test_i18ngrep' read the file without redirection t5510: consolidate 'grep' and 'test_i18ngrep' patterns t4001: don't run 'git status' upstream of a pipe t6022: don't run 'git merge' upstream of a pipe t5812: add 'test_i18ngrep's missing filename parameter t5541: add 'test_i18ngrep's missing filename parameter
2018-02-16test-lib.sh: unset XDG_CACHE_HOMELibravatar Genki Sky1-0/+1
git respects XDG_CACHE_HOME for the credential cache. So, we should unset XDG_CACHE_HOME for the test environment, lest a user's custom one cause failure in the test. For example, t/t0301-credential-cache.sh expects a default directory to be used if it hasn't explicitly set XDG_CACHE_HOME. Signed-off-by: Genki Sky <sky@genki.is> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-15Merge branch 'ab/wildmatch-tests'Libravatar Junio C Hamano1-0/+4
More tests for wildmatch functions. * ab/wildmatch-tests: wildmatch test: mark test as EXPENSIVE_ON_WINDOWS test-lib: add an EXPENSIVE_ON_WINDOWS prerequisite wildmatch test: create & test files on disk in addition to in-memory wildmatch test: perform all tests under all wildmatch() modes wildmatch test: use test_must_fail, not ! for test-wildmatch wildmatch test: remove dead fnmatch() test code wildmatch test: use a paranoia pattern from nul_match() wildmatch test: don't try to vertically align our output wildmatch test: use more standard shell style wildmatch test: indent with tabs, not spaces
2018-02-13Merge branch 'ab/simplify-perl-makefile'Libravatar Junio C Hamano1-1/+1
The build procedure for perl/ part has been greatly simplified by weaning ourselves off of MakeMaker. * ab/simplify-perl-makefile: perl: treat PERLLIB_EXTRA as an extra path again perl: avoid *.pmc and fix Error.pm further Makefile: replace perl/Makefile.PL with simple make rules
2018-02-08t: move 'test_i18ncmp' and 'test_i18ngrep' to 'test-lib-functions.sh'Libravatar SZEDER Gábor1-26/+0
Both 'test_i18ncmp' and 'test_i18ngrep' helper functions are supposed to be called from our test scripts, so they should be in 'test-lib-functions.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-30test-lib: add an EXPENSIVE_ON_WINDOWS prerequisiteLibravatar Ævar Arnfjörð Bjarmason1-0/+4
Add an EXPENSIVE_ON_WINDOWS prerequisite to mark those tests which are very expensive to run on Windows, but cheap elsewhere. Certain tests that heavily stress the filesystem or run a lot of shell commands are disproportionately expensive on Windows, this prerequisite will later be used by a tests that runs in 4-8 seconds on a modern Linux system, but takes almost 10 minutes on Windows. There's no reason to skip such tests by default on other platforms, but Windows users shouldn't need to wait around while they finish. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-05Merge branch 'jk/test-suite-tracing'Libravatar Junio C Hamano1-13/+33
Assorted fixes around running tests with "-x" tracing option. * jk/test-suite-tracing: t/Makefile: introduce TEST_SHELL_PATH test-lib: make "-x" work with "--verbose-log" t5615: avoid re-using descriptor 4 test-lib: silence "-x" cleanup under bash
2017-12-11Makefile: replace perl/Makefile.PL with simple make rulesLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Replace the perl/Makefile.PL and the fallback perl/Makefile used under NO_PERL_MAKEMAKER=NoThanks with a much simpler implementation heavily inspired by how the i18n infrastructure's build process works[1]. The reason for having the Makefile.PL in the first place is that it was initially[2] building a perl C binding to interface with libgit, this functionality, that was removed[3] before Git.pm ever made it to the master branch. We've since since started maintaining a fallback perl/Makefile, as MakeMaker wouldn't work on some platforms[4]. That's just the tip of the iceberg. We have the PM.stamp hack in the top-level Makefile[5] to detect whether we need to regenerate the perl/perl.mak, which I fixed just recently to deal with issues like the perl version changing from under us[6]. There is absolutely no reason for why this needs to be so complex anymore. All we're getting out of this elaborate Rube Goldberg machine was copying perl/* to perl/blib/* as we do a string-replacement on the *.pm files to hardcode @@LOCALEDIR@@ in the source, as well as pod2man-ing Git.pm & friends. So replace the whole thing with something that's pretty much a copy of how we generate po/build/**.mo from po/*.po, just with a small sed(1) command instead of msgfmt. As that's being done rename the files from *.pm to *.pmc just to indicate that they're generated (see "perldoc -f require"). While I'm at it, change the fallback for Error.pm from being something where we'll ship our own Error.pm if one doesn't exist at build time to one where we just use a Git::Error wrapper that'll always prefer the system-wide Error.pm, only falling back to our own copy if it really doesn't exist at runtime. It's now shipped as Git::FromCPAN::Error, making it easy to add other modules to Git::FromCPAN::* in the future if that's needed. Functional changes: * This will not always install into perl's idea of its global "installsitelib". This only potentially matters for packagers that need to expose Git.pm for non-git use, and as explained in the INSTALL file there's a trivial workaround. * The scripts themselves will 'use lib' the target directory, but if INSTLIBDIR is set it overrides it. It doesn't have to be this way, it could be set in addition to INSTLIBDIR, but my reading of [7] is that this is the desired behavior. * We don't build man pages for all of the perl modules as we used to, only Git(3pm). As discussed on-list[8] that we were building installed manpages for purely internal APIs like Git::I18N or private-Error.pm was always a bug anyway, and all the Git::SVN::* ones say they're internal APIs. There are apparently external users of Git.pm, but I don't expect there to be any of the others. As a side-effect of these general changes the perl documentation now only installed by install-{doc,man}, not a mere "install" as before. 1. 5e9637c629 ("i18n: add infrastructure for translating Git with gettext", 2011-11-18) 2. b1edc53d06 ("Introduce Git.pm (v4)", 2006-06-24) 3. 18b0fc1ce1 ("Git.pm: Kill Git.xs for now", 2006-09-23) 4. f848718a69 ("Make perl/ build procedure ActiveState friendly.", 2006-12-04) 5. ee9be06770 ("perl: detect new files in MakeMaker builds", 2012-07-27) 6. c59c4939c2 ("perl: regenerate perl.mak if perl -V changes", 2017-03-29) 7. 0386dd37b1 ("Makefile: add PERLLIB_EXTRA variable that adds to default perl path", 2013-11-15) 8. 87bmjjv1pu.fsf@evledraar.booking.com ("Re: [PATCH] Makefile: replace perl/Makefile.PL with simple make rules" Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08t/Makefile: introduce TEST_SHELL_PATHLibravatar Jeff King1-1/+1
You may want to run the test suite with a different shell than you use to build Git. For instance, you may build with SHELL_PATH=/bin/sh (because it's faster, or it's what you expect to exist on systems where the build will be used) but want to run the test suite with bash (e.g., since that allows using "-x" reliably across the whole test suite). There's currently no good way to do this. You might think that doing two separate make invocations, like: make && make -C t SHELL_PATH=/bin/bash would work. And it _almost_ does. The second make will see our bash SHELL_PATH, and we'll use that to run the individual test scripts (or tell prove to use it to do so). So far so good. But this breaks down when "--tee" or "--verbose-log" is used. Those options cause the test script to actually re-exec itself using $SHELL_PATH. But wait, wouldn't our second make invocation have set SHELL_PATH correctly in the environment? Yes, but test-lib.sh sources GIT-BUILD-OPTIONS, which we built during the first "make". And that overrides the environment, giving us the original SHELL_PATH again. Let's introduce a new variable that lets you specify a specific shell to be run for the test scripts. Note that we have to touch both the main and t/ Makefiles, since we have to record it in GIT-BUILD-OPTIONS in one, and use it in the latter. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08test-lib: make "-x" work with "--verbose-log"Libravatar Jeff King1-2/+8
The "-x" tracing option implies "--verbose". This is a problem when running under a TAP harness like "prove", where we need to use "--verbose-log" instead. Instead, let's handle this the same way we do for --valgrind, including the recent fix from 88c6e9d31c (test-lib: --valgrind should not override --verbose-log, 2017-09-05). Namely, let's enable --verbose only when we know there isn't a more specific verbosity option indicated. Note that we also have to tweak `want_trace` to turn it on (previously we just lumped $verbose_log in with $verbose, but now we don't necessarily auto-set the latter). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-08test-lib: silence "-x" cleanup under bashLibravatar Jeff King1-10/+24
When the test suite's "-x" option is used with bash, we end up seeing cleanup cruft in the output: $ bash t0001-init.sh -x [...] ++ diff -u expected actual + test_eval_ret_=0 + want_trace + test t = t + test t = t + set +x ok 42 - re-init from a linked worktree This ranges from mildly annoying (for a successful test) to downright confusing (when we say "last command exited with error", but it's really 5 commands back). We normally are able to suppress this cleanup. As the in-code comment explains, we can't convince the shell not to print it, but we can redirect its stderr elsewhere. But since d88785e424 (test-lib: set BASH_XTRACEFD automatically, 2016-05-11), that doesn't hold for bash. It sends the "set -x" output directly to descriptor 4, not to stderr. We can fix this by also redirecting descriptor 4, and paying close attention to which commands redirected and which are not (see the updated comment). Two alternatives I considered and rejected: - unsetting and setting BASH_XTRACEFD; doing so closes the descriptor, which we must avoid - we could keep everything in a single block as before, redirect 4>/dev/null there, but retain 5>&4 as a copy. And then selectively restore 4>&5 for commands which should be allowed to trace. This would work, but the descriptor swapping seems unnecessarily confusing. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-24test-lib: add LIBPCRE1 & LIBPCRE2 prerequisitesLibravatar Ævar Arnfjörð Bjarmason1-0/+2
Add LIBPCRE1 and LIBPCRE2 prerequisites which are true when git is compiled with USE_LIBPCRE1=YesPlease or USE_LIBPCRE2=YesPlease, respectively. The syntax of PCRE1 and PCRE2 isn't the same in all cases (see pcresyntax(3) and pcre2syntax(3)). If test are added that test for those they'll need to be guarded by these new prerequisites. The subsequent patch will make use of LIBPCRE2, so LIBPCRE1 isn't strictly needed for now, but let's add it for consistency and so that checking for it doesn't have to be done with the less obvious "PCRE, !LIBPCRE2", which while semantically the same is more confusing, and would lead to bugs if PCRE v3 is ever released as the tests would mean v1, not any non-v2 version. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-21Merge branch 'cb/t4201-robustify' into maintLibravatar Junio C Hamano1-3/+4
A test update. * cb/t4201-robustify: t4201: make use of abbreviation in the test more robust
2017-11-15Merge branch 'cb/t4201-robustify'Libravatar Junio C Hamano1-3/+4
A test update. * cb/t4201-robustify: t4201: make use of abbreviation in the test more robust
2017-11-13t4201: make use of abbreviation in the test more robustLibravatar Charles Bailey1-3/+4
The test for '--abbrev' in t4201-shortlog.sh assumes that the commits generated in the test can always be uniquely abbreviated to 5 hex digits but this is not always the case. If you were unlucky and happened to run the test at (say) Thu Jun 22 03:04:49 2017 +0000, you would find that the first commit generated would collide with a tree object created later in the same test. This can be simulated in the version of t4201-shortlog.sh prior to this commit by setting GIT_COMMITTER_DATE and GIT_AUTHOR_DATE to 1498100689 after sourcing test-lib.sh. Change the test to test --abbrev=35 instead of --abbrev=5 to almost completely avoid the possibility of a partial collision and add a call to test_tick in the setup to make the test repeatable (the latter alone is sufficient to make it robust enough). Signed-off-by: Charles Bailey <cbailey32@bloomberg.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-18Merge branch 'jk/drop-sha1-entry-pos' into maintLibravatar Junio C Hamano1-1/+0
Code clean-up. * jk/drop-sha1-entry-pos: sha1-lookup: remove sha1_entry_pos() from header file sha1_file: drop experimental GIT_USE_LOOKUP search
2017-09-25Merge branch 'rj/test-ulimit-on-windows'Libravatar Junio C Hamano1-10/+10
On Cygwin, "ulimit -s" does not report failure but it does not work at all, which causes an unexpected success of some tests that expect failures under a limited stack situation. This has been fixed. * rj/test-ulimit-on-windows: t9010-*.sh: skip all tests if the PIPE prereq is missing test-lib: use more compact expression in PIPE prerequisite test-lib: don't use ulimit in test prerequisites on cygwin
2017-09-25Merge branch 'mg/name-rev-tests-with-short-stack'Libravatar Junio C Hamano1-0/+6
A handful of tests to demonstrates a recursive implementation of "name-rev" hurts. * mg/name-rev-tests-with-short-stack: t6120: test describe and name-rev with deep repos t6120: clean up state after breaking repo t6120: test name-rev --all and --stdin t7004: move limited stack prereq to test-lib
2017-09-19test-lib: use more compact expression in PIPE prerequisiteLibravatar Ramsay Jones1-8/+2
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-15test-lib: don't use ulimit in test prerequisites on cygwinLibravatar Ramsay Jones1-2/+8
On cygwin (and MinGW), the 'ulimit' built-in bash command does not have the desired effect of limiting the resources of new processes, at least for the stack and file descriptors. However, it always returns success and leads to several test prerequisites being erroneously set to true. Add a check for cygwin and MinGW to the prerequisite expressions, using a 'test_have_prereq !MINGW,!CYGWIN' clause, to guard against using ulimit. This affects the prerequisite expressions for the ULIMIT_STACK_SIZE, CMDLINE_LIMIT and ULIMIT_FILE_DESCRIPTORS prerequisites. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-10Merge branch 'rs/t1002-do-not-use-sum' into maintLibravatar Junio C Hamano1-3/+0
Test simplification. * rs/t1002-do-not-use-sum: t1002: stop using sum(1)
2017-09-08t7004: move limited stack prereq to test-libLibravatar Michael J Gruber1-0/+6
The lazy prerequisite ULIMIT_STACK_SIZE is used only in t7004 so far. Move it to test-lib.sh so that it can be used in other tests (which it will be in a follow-up commit). Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-06test-lib: set LSAN_OPTIONS to abort by defaultLibravatar Jeff King1-0/+5
We already set ASAN_OPTIONS to abort if it finds any errors. As we start to experiment with LSAN, the leak sanitizer, it's convenient if we give it the same treatment. Note that ASAN is actually a superset of LSAN and can do the leak detection itself. So this only has an effect if you specifically build with "make SANITIZE=leak" (leak detection but not the rest of ASAN). Building with just LSAN results in a build that runs much faster. That makes the build-test-fix cycle more pleasant. In the long run, once we've fixed or suppressed all the leaks, it will probably be worth turning leak-detection on for ASAN and just using that (to check both leaks _and_ memory errors in a single test run). But there's still a lot of work before we get there. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-06test-lib: --valgrind should not override --verbose-logLibravatar Jeff King1-1/+1
The --verbose test option cannot be used with test harnesses like "prove". Instead, you must use --verbose-log. Since the --valgrind option implies --verbose, that means that it cannot be used with prove. I.e., this does not work: prove t0000-basic.sh :: --valgrind You'd think it could be fixed by doing: prove t0000-basic.sh :: --valgrind --verbose-log but that doesn't work either, because the implied --verbose takes precedence over --verbose-log. If the user has given us a specific option, we should prefer that. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-23Merge branch 'rs/t1002-do-not-use-sum'Libravatar Junio C Hamano1-3/+0
Test simplification. * rs/t1002-do-not-use-sum: t1002: stop using sum(1)
2017-08-22Merge branch 'jk/drop-sha1-entry-pos'Libravatar Junio C Hamano1-1/+0
Code clean-up. * jk/drop-sha1-entry-pos: sha1_file: drop experimental GIT_USE_LOOKUP search
2017-08-15t1002: stop using sum(1)Libravatar René Scharfe1-3/+0
sum(1) is a command for calculating checksums of the contents of files. It was part of early editions of Unix ("Research Unix", 1972/1973, [1]). cksum(1) appeared in 4.4BSD (1993) as a replacement [2], and became part of POSIX.1-2008 [3]. OpenBSD 5.6 (2014) removed sum(1). We only use sum(1) in t1002 to check for changes in three files. On MinGW we use md5sum(1) instead. We could switch to the standard command cksum(1) for all platforms; MinGW comes with GNU coreutils now, which provides sum(1), cksum(1) and md5sum(1). Use our standard method for checking for file changes instead: test_cmp. It's more convenient because it shows differences nicely, it's faster on MinGW because we have a special implementation there based only on shell-internal commands, it's simpler as it allows us to avoid stripping out unnecessary entries from the checksum file using grep(1), and it's more consistent with the rest of the test suite. We already compare changed files with their expected new contents using diff(1), so we don't need to check with "test_must_fail test_cmp" if they differ from their original state. A later patch could convert the direct diff(1) calls to test_cmp as well. With all sum(1) calls gone, remove the MinGW-specific implementation from test-lib.sh as well. [1] http://minnie.tuhs.org/cgi-bin/utree.pl?file=V3/man/man1/sum.1 [2] http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.4BSD/usr/share/man/cat1/cksum.0 [3] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cksum.html Signed-off-by: René Scharfe <l.s.r@web.de> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-09sha1_file: drop experimental GIT_USE_LOOKUP searchLibravatar Jeff King1-1/+0
Long ago in 628522ec14 (sha1-lookup: more memory efficient search in sorted list of SHA-1, 2007-12-29) we added sha1_entry_pos(), a binary search that uses the uniform distribution of sha1s to scale the selection of mid-points. As this was a performance experiment, we tied it to the GIT_USE_LOOKUP environment variable and never enabled it by default. This code was successful in reducing the number of steps in each search. But the overhead of the scaling ends up making it slower when the cache is warm. Here are best-of-five timings for running rev-list on linux.git, which will have to look up every object: $ time git rev-list --objects --all >/dev/null real 0m35.357s user 0m35.016s sys 0m0.340s $ time GIT_USE_LOOKUP=1 git rev-list --objects --all >/dev/null real 0m37.364s user 0m37.045s sys 0m0.316s The USE_LOOKUP version might have more benefit on a cold cache, as the time to fault in each page would dominate. But that would be for a single lookup. In practice, most operations tend to look up many objects, and the whole pack .idx will end up warm. It's possible that the code could be better optimized to compete with a naive binary search for the warm-cache case, and we could have the best of both worlds. But over the years nobody has done so, and this is largely dead code that is rarely run outside of the test suite. Let's drop it in the name of simplicity. This lets us remove sha1_entry_pos() entirely, as the .idx lookup code was the only caller. Note that sha1-lookup.c still contains sha1_pos(), which differs from sha1_entry_pos() in two ways: - it has a different interface; it uses a function pointer to access sha1 entries rather than a size/offset pair describing the table's memory layout - it only scales the initial selection of "mi", rather than each iteration of the search We can't get rid of this function, as it's called from several places. It may be that we could replace it with a simple binary search, but that's out of scope for this patch (and would need benchmarking). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13Merge branch 'jk/build-with-asan'Libravatar Junio C Hamano1-3/+8
The build procedure has been improved to allow building and testing Git with address sanitizer more easily. * jk/build-with-asan: Makefile: disable unaligned loads with UBSan Makefile: turn off -fomit-frame-pointer with sanitizers Makefile: add helper for compiling with -fsanitize test-lib: turn on ASan abort_on_error by default test-lib: set ASAN_OPTIONS variable before we run git
2017-07-10test-lib: turn on ASan abort_on_error by defaultLibravatar Jeff King1-1/+1
By default, ASan will exit with code 1 when it sees an error. This means we'll notice a problem when we expected git to succeed, but not in a test_must_fail block. Let's ask it to actually raise SIGABRT instead. That will give us a signal death that test_must_fail will notice. As a bonus, it may also leave a coredump, which can be handy for digging into a failure. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-10test-lib: set ASAN_OPTIONS variable before we run gitLibravatar Jeff King1-3/+8
We turn off ASan's leak detection by default in the test suite because it's too noisy. But we don't do so until part-way through test-lib. This is before we've run any tests, but after we do our initial "./git" to see if the binary has even been built. When built with clang, this seems to work fine. However, using "gcc -fsanitize=address", the leak checker seems to complain more aggressively: $ ./git ... ==5352==ERROR: LeakSanitizer: detected memory leaks Direct leak of 2 byte(s) in 1 object(s) allocated from: #0 0x7f120e7afcf8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1cf8) #1 0x559fc2a3ce41 in do_xmalloc /home/peff/compile/git/wrapper.c:60 #2 0x559fc2a3cf1a in do_xmallocz /home/peff/compile/git/wrapper.c:100 #3 0x559fc2a3d0ad in xmallocz /home/peff/compile/git/wrapper.c:108 #4 0x559fc2a3d0ad in xmemdupz /home/peff/compile/git/wrapper.c:124 #5 0x559fc2a3d0ad in xstrndup /home/peff/compile/git/wrapper.c:130 #6 0x559fc274535a in main /home/peff/compile/git/common-main.c:39 #7 0x7f120dabd2b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0) This is a leak in the sense that we never free it, but it's in a global that is meant to last the whole program. So it's not really interesting or in need of fixing. And at any rate, mentioning leaks outside of the test_expect blocks is certainly unwelcome, as it pollutes stderr. Let's bump the setting of ASAN_OPTIONS higher in test-lib.sh to catch our initial "can we even run git?" test. While we're at it, we can add a comment to make it a bit less inscrutable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-19Merge branch 'ab/pcre-v2'Libravatar Junio C Hamano1-1/+1
Update "perl-compatible regular expression" support to enable JIT and also allow linking with the newer PCRE v2 library. * ab/pcre-v2: grep: add support for PCRE v2 grep: un-break building with PCRE >= 8.32 without --enable-jit grep: un-break building with PCRE < 8.20 grep: un-break building with PCRE < 8.32 grep: add support for the PCRE v1 JIT API log: add -P as a synonym for --perl-regexp grep: skip pthreads overhead when using one thread grep: don't redundantly compile throwaway patterns under threading
2017-06-02Merge branch 'ab/grep-preparatory-cleanup'Libravatar Junio C Hamano1-1/+2
The internal implementation of "git grep" has seen some clean-up. * ab/grep-preparatory-cleanup: (31 commits) grep: assert that threading is enabled when calling grep_{lock,unlock} grep: given --threads with NO_PTHREADS=YesPlease, warn pack-objects: fix buggy warning about threads pack-objects & index-pack: add test for --threads warning test-lib: add a PTHREADS prerequisite grep: move is_fixed() earlier to avoid forward declaration grep: change internal *pcre* variable & function names to be *pcre1* grep: change the internal PCRE macro names to be PCRE1 grep: factor test for \0 in grep patterns into a function grep: remove redundant regflags assignments grep: catch a missing enum in switch statement perf: add a comparison test of log --grep regex engines with -F perf: add a comparison test of log --grep regex engines perf: add a comparison test of grep regex engines with -F perf: add a comparison test of grep regex engines perf: emit progress output when unpacking & building perf: add a GIT_PERF_MAKE_COMMAND for when *_MAKE_OPTS won't do grep: add tests to fix blind spots with \0 patterns grep: prepare for testing binary regexes containing rx metacharacters grep: add a test helper function for less verbose -f \0 tests ...