kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
brian m. carlson	bd981d5fc3	t/test-lib: introduce OID_REGEX 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>	7 years ago
brian m. carlson	198857bf7e	t/test-lib: introduce ZERO_OID 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>	7 years ago
brian m. carlson	d16ab63429	t/test-lib: add an SHA1 prerequisite 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>	7 years ago
Jeff King	e9184b0789	t5561: skip tests if curl is not available 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>	7 years ago
Nguyễn Thái Ngọc Duy	a801a7cfc7	t/helper: merge test-date into test-tool Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Nguyễn Thái Ngọc Duy	0e496492d2	t/helper: merge test-chmtime into test-tool Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
SZEDER Gábor	5fc98e79fc	t: add means to disable '-x' tracing for individual test scripts 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>	7 years ago
Genki Sky	7976e901c8	test-lib.sh: unset XDG_CACHE_HOME 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>	7 years ago
SZEDER Gábor	0f59128f7b	t: move 'test_i18ncmp' and 'test_i18ngrep' to 'test-lib-functions.sh' 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>	7 years ago
Ævar Arnfjörð Bjarmason	5b1fe6ebb7	test-lib: add an EXPENSIVE_ON_WINDOWS prerequisite 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>	7 years ago
Ævar Arnfjörð Bjarmason	20d2a30f8f	Makefile: replace perl/Makefile.PL with simple make rules 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>	7 years ago
Jeff King	3f824e91c8	t/Makefile: introduce TEST_SHELL_PATH 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>	7 years ago
Jeff King	f5ba2de6bc	test-lib: make "-x" work with "--verbose-log" 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>	7 years ago
Jeff King	90c8a1db9d	test-lib: silence "-x" cleanup under bash 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>	7 years ago
Ævar Arnfjörð Bjarmason	ce9a257031	test-lib: add LIBPCRE1 & LIBPCRE2 prerequisites 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>	7 years ago
Charles Bailey	5555a2aa4b	t4201: make use of abbreviation in the test more robust 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>	7 years ago
Ramsay Jones	7b7bea23ac	test-lib: use more compact expression in PIPE prerequisite 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>	8 years ago
Ramsay Jones	21dac1deee	test-lib: don't use ulimit in test prerequisites on cygwin 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>	8 years ago
Michael J Gruber	4db464f815	t7004: move limited stack prereq to test-lib 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>	8 years ago
Jeff King	85b81b35ff	test-lib: set LSAN_OPTIONS to abort by default 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>	8 years ago
Jeff King	88c6e9d31c	test-lib: --valgrind should not override --verbose-log 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>	8 years ago
René Scharfe	70ec6bd63b	t1002: stop using sum(1) 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>	8 years ago
Jeff King	f1068efefe	sha1_file: drop experimental GIT_USE_LOOKUP search 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>	8 years ago
Jeff King	bf1ce904b7	test-lib: turn on ASan abort_on_error by default 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>	8 years ago
Jeff King	d0cc5796f3	test-lib: set ASAN_OPTIONS variable before we run git 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>	8 years ago
Ævar Arnfjörð Bjarmason	94da9193a6	grep: add support for PCRE v2 Add support for v2 of the PCRE API. This is a new major version of PCRE that came out in early 2015[1]. The regular expression syntax is the same, but while the API is similar, pretty much every function is either renamed or takes different arguments. Thus using it via entirely new functions makes sense, as opposed to trying to e.g. have one compile_pcre_pattern() that would call either PCRE v1 or v2 functions. Git can now be compiled with either USE_LIBPCRE1=YesPlease or USE_LIBPCRE2=YesPlease, with USE_LIBPCRE=YesPlease currently being a synonym for the former. Providing both is a compile-time error. With earlier patches to enable JIT for PCRE v1 the performance of the release versions of both libraries is almost exactly the same, with PCRE v2 being around 1% slower. However after I reported this to the pcre-dev mailing list[2] I got a lot of help with the API use from Zoltán Herczeg, he subsequently optimized some of the JIT functionality in v2 of the library. Running the p7820-grep-engines.sh performance test against the latest Subversion trunk of both, with both them and git compiled as -O3, and the test run against linux.git, gives the following results. Just the /perl/ tests shown: $ GIT_PERF_REPEAT_COUNT=30 GIT_PERF_LARGE_REPO=~/g/linux GIT_PERF_MAKE_COMMAND='grep -q LIBPCRE2 Makefile && make -j8 USE_LIBPCRE2=YesPlease CC=~/perl5/installed/bin/gcc NO_R_TO_GCC_LINKER=YesPlease CFLAGS=-O3 LIBPCREDIR=/home/avar/g/pcre2/inst LDFLAGS=-Wl,-rpath,/home/avar/g/pcre2/inst/lib \|\| make -j8 USE_LIBPCRE=YesPlease CC=~/perl5/installed/bin/gcc NO_R_TO_GCC_LINKER=YesPlease CFLAGS=-O3 LIBPCREDIR=/home/avar/g/pcre/inst LDFLAGS=-Wl,-rpath,/home/avar/g/pcre/inst/lib' ./run HEAD~5 HEAD~ HEAD p7820-grep-engines.sh [...] Test HEAD~5 HEAD~ HEAD ----------------------------------------------------------------------------------------------------------------- 7820.3: perl grep 'how.to' 0.31(1.10+0.48) 0.21(0.35+0.56) -32.3% 0.21(0.34+0.55) -32.3% 7820.7: perl grep '^how to' 0.56(2.70+0.40) 0.24(0.64+0.52) -57.1% 0.20(0.28+0.60) -64.3% 7820.11: perl grep '[how] to' 0.56(2.66+0.38) 0.29(0.95+0.45) -48.2% 0.23(0.45+0.54) -58.9% 7820.15: perl grep '(e.t[^ ]\|v.ry) rare' 1.02(5.77+0.42) 0.31(1.02+0.54) -69.6% 0.23(0.50+0.54) -77.5% 7820.19: perl grep 'm(ú\|u)lt.b(æ\|y)te' 0.38(1.57+0.42) 0.27(0.85+0.46) -28.9% 0.21(0.33+0.57) -44.7% See commit ("perf: add a comparison test of grep regex engines", 2017-04-19) for details on the machine the above test run was executed on. Here HEAD~2 is git with PCRE v1 without JIT, HEAD~ is PCRE v1 with JIT, and HEAD is PCRE v2 (also with JIT). See previous commits of mine mentioning p7820-grep-engines.sh for more details on the test setup. For ease of readability, a different run just of HEAD~ (PCRE v1 with JIT v.s. PCRE v2), again with just the /perl/ tests shown: [...] Test HEAD~ HEAD ---------------------------------------------------------------------------------------- 7820.3: perl grep 'how.to' 0.21(0.42+0.52) 0.21(0.31+0.58) +0.0% 7820.7: perl grep '^how to' 0.25(0.65+0.50) 0.20(0.31+0.57) -20.0% 7820.11: perl grep '[how] to' 0.30(0.90+0.50) 0.23(0.46+0.53) -23.3% 7820.15: perl grep '(e.t[^ ]\|v.ry) rare' 0.30(1.19+0.38) 0.23(0.51+0.51) -23.3% 7820.19: perl grep 'm(ú\|u)lt.b(æ\|y)te' 0.27(0.84+0.48) 0.21(0.34+0.57) -22.2% I.e. the two are either neck-to-neck, but PCRE v2 usually pulls ahead, when it does it's around 20% faster. A brief note on thread safety: As noted in pcre2api(3) & pcre2jit(3) the compiled pattern can be shared between threads, but not some of the JIT context, however the grep threading support does all pattern & JIT compilation in separate threads, so this code doesn't need to concern itself with thread safety. See commit `63e7e9d8b6` ("git-grep: Learn PCRE", 2011-05-09) for the initial addition of PCRE v1. This change follows some of the same patterns it did (and which were discussed on list at the time), e.g. mocking up types with typedef instead of ifdef-ing them out when USE_LIBPCRE2 isn't defined. This adds some trivial memory use to the program, but makes the code look nicer. 1. https://lists.exim.org/lurker/message/20150105.162835.0666407a.en.html 2. https://lists.exim.org/lurker/thread/20170419.172322.833ee099.en.html Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Ævar Arnfjörð Bjarmason	68c7d2761d	test-lib: add a PTHREADS prerequisite Add a PTHREADS prerequisite which is false when git is compiled with NO_PTHREADS=YesPlease. There's lots of custom code that runs when threading isn't available, but before this prerequisite there was no way to test it. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Ævar Arnfjörð Bjarmason	3485bea157	grep: change the internal PCRE macro names to be PCRE1 Change the internal USE_LIBPCRE define, & build options flag to use a naming convention ending in PCRE1, without changing the long-standing USE_LIBPCRE Makefile flag which enables this code. This is for preparation for libpcre2 support where having things like USE_LIBPCRE and USE_LIBPCRE2 in any more places than we absolutely need to for backwards compatibility with old Makefile arguments would be confusing. In some ways it would be better to change everything that now uses USE_LIBPCRE to use USE_LIBPCRE1, and to make specifying USE_LIBPCRE (or --with-pcre) an error. This would impose a one-time burden on packagers of git to s/USE_LIBPCRE/USE_LIBPCRE1/ in their build scripts. However I'd like to leave the door open to making USE_LIBPCRE=YesPlease eventually mean USE_LIBPCRE2=YesPlease, i.e. once PCRE v2 is ubiquitous enough that it makes sense to make it the default. This code and the USE_LIBPCRE Makefile argument was added in commit `63e7e9d8b6` ("git-grep: Learn PCRE", 2011-05-09). At the time there was no indication that the PCRE project would release an entirely new & incompatible API around 3 years later. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Ævar Arnfjörð Bjarmason	3eb585c112	test-lib: rename the LIBPCRE prerequisite to PCRE Rename the LIBPCRE prerequisite to PCRE. This is for preparation for libpcre2 support, where having just "LIBPCRE" would be confusing as it implies v1 of the library. None of these tests are incompatible between versions 1 & 2 of libpcre, it's less confusing to give them a more general name to make it clear that they work on both library versions. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Junio C Hamano	c7018be509	test: allow skipping the remainder Because TAP output does not like to see the remainder of the test getting skipped after running one or more tests, `bf4b7219` ("test-lib.sh: Add check for invalid use of 'skip_all' facility", 2012-09-01) made sure that test_done errors out when this happens. Instead, loosen the check so that we only pretend that the rest of the test script did not exist in such a case. We'd lose a bit of information (i.e. TAP does not notice that we are skipping some tests), but not very much (i.e. TAP wasn't told how many tests are skipped anyway). This will allow inclusion of lib-httpd.sh in the middle of a test, which will skip the remainder of the test scripts when tests that involve web server are declined with GIT_TEST_HTTPD=false, for example. Acked-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Junio C Hamano	06478dab4c	test-lib: retire $remove_trash variable The convention "$remove_trash is set to the trash directory that is used during the test, so that it will be removed at the end, but under --debug option we set the varilable to empty string to preserve the directory" made sense back when it was introduced, as there was no $TRASH_DIRECTORY variable. These days, since no tests looks at the variable, it is obscure and even risks that by mistake the variable gets used for something else (e.g. remove_trash=yes) and cause us misbehave. Worse yet, remove_trash was not initialized to an empty string at the beginning, so a stray environment variable the user has could have affected the logic when "--debug" is in use. Rewrite the clean-up sequence in test_done helper to explicitly check the $debug condition and remove the trash directory using the $TRASH_DIRECTORY variable. Note that "go to the directory one level above the trash and then remove it" is kept and this is deliverate; test_at_end_hook_ will keep running from the expected location, and also some platforms may not like a directory that is serving as the $cwd of a still-active process removed. Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Junio C Hamano	4d0912a206	test-lib.sh: do not barf under --debug at the end of the test The original did "does $remove_trash exist? Then go one level above and remove it". There was no problem under "--debug", where the variable is left empty, as the first "test -d $remove_trash" would have said "No, it doesn't". With the check implemented in the previous step, we'd always get an error under "--debug". Noticed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	df4c0d1a79	test-lib: abort when can't remove trash directory We had two similar bugs in the tests sporadically triggering error messages during the removal of the trash directory, see commits `bb05510e5` (t5510: run auto-gc in the foreground, 2016-05-01) and `ef09036cf` (t6500: wait for detached auto gc at the end of the test script, 2017-04-13). The test script succeeded nonetheless, because these errors are ignored during housekeeping in 'test_done'. However, such an error is a sign that something is fishy in the test script. Print an error message and abort the test script when the trash directory can't be removed successfully or is already removed, because that's unexpected and we would prefer somebody notice and figure out why. 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>	8 years ago
Johannes Schindelin	efac8ac84b	t0006 & t5000: skip "far in the future" test when time_t is too limited Git's source code refers to timestamps as unsigned long, which is ill-defined, as there is no guarantee about the number of bits that data type has. In preparation of switching to another data type that is large enough to hold "far in the future" dates, we need to prepare the t0006-date.sh script for the case where we still cannot format those dates if the system library uses 32-bit time_t. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Johannes Schindelin	a07fb0507f	t0006 & t5000: prepare for 64-bit timestamps Git's source code refers to timestamps as unsigned longs. On 32-bit platforms, as well as on Windows, unsigned long is not large enough to capture dates that are "absurdly far in the future". It is perfectly valid by the C standard, of course, for the `long` data type to refer to 32-bit integers. That is why the `time_t` data type exists: so that it can be 64-bit even if `long` is 32-bit. Git's source code simply uses an incorrect data type for timestamps, is all. The earlier quick fix `6b9c38e14c` (t0006: skip "far in the future" test when unsigned long is not long enough, 2016-07-11) papered over this issue simply by skipping the respective test cases on platforms where they would fail due to the data type in use. This quick fix, however, tests for long to be 64-bit or not. What we need, though, is a test that says whether whatever data type we use for timestamps is 64-bit or not. The same quick fix was used to handle the similar problem where Git's source code uses `unsigned long` to represent size, instead of `size_t`, conflating the two issues. So let's just add another prerequisite to test specifically whether timestamps are represented by a 64-bit data type or not. Later, after we switch to a larger data type, we can flip that prerequisite to test `time_t` instead of `long`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Junio C Hamano	99a64e4b73	tests: lint for run-away here-doc We found a few run-away here documents that are started with an end-of-here-doc marker that is incorrectly spelled, e.g. git some command >actual && cat <<EOF >expect ... EOF && test_cmp expect actual which ends up slurping the entire remainder of the script as if it were the data. Often the command that gets misused like this exits without failure (e.g. "cat" in the above example), which makes the command appear to work, without ever executing the remainder of the test. Piggy-back on the test that catches &&-chain breakage to detect this case as well. Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	4ecae3c8c1	tests: create an interactive gdb session with the 'debug' helper The 'debug' test helper is supposed to facilitate debugging by running a command of the test suite under gdb. Unfortunately, its usefulness is severely limited, because that gdb session is not interactive, since the test's, and thus gdb's standard input is redirected from /dev/null (for a good reason, see `781f76b15` (test-lib: redirect stdin of tests, 2011-12-15)). Redirect gdb's standard file descriptors from/to the test environment's stdin, stdout and stderr in the 'debug' helper, thus creating an interactive gdb session (even in non-verbose mode), which is much, much more useful. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Johannes Schindelin	d98b2c5fce	test-lib: on FreeBSD, look for unzip(1) in /usr/local/bin/ Eric Wong reported that while FreeBSD has a /usr/bin/unzip, it uses different semantics from those that are needed by Git's tests: When passing the -a option to Info-Zip, it heeds the text attribute of the .zip file's central directory, while FreeBSD's unzip ignores that attribute. The common work-around is to install Info-Zip on FreeBSD, into /usr/local/bin/. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Tested-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
René Scharfe	28fab7b23d	valgrind: support test helpers Tests run with --valgrind call git commands through a wrapper script that invokes valgrind on them. This script (valgrind.sh) is in turn invoked through symlinks created for each command in t/valgrind/bin/. Since `e6e7530d` (test helpers: move test-* to t/helper/ subdirectory) these symlinks have been broken for test helpers -- they point to the old locations in the root of the build directory. Fix that by teaching the code for creating the links about the new location of the binaries, and do the same in the wrapper script to allow it to find its payload. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Jeff King	614fe01521	test-lib: bail out when "-v" used under "prove" When there is a TAP harness consuming the output of our test scripts, the "--verbose" breaks the output by mingling test command output with TAP. Because the TAP::Harness module used by "prove" is fairly lenient, this _usually_ works, but it violates the spec, and things get very confusing if the commands happen to output a line that looks like TAP (e.g., the word "ok" on its own line). Let's detect this situation and complain. Just calling error() isn't great, though; prove will tell us that the script failed, but the message doesn't make it through to the user. Instead, we can use the special TAP signal "Bail out!". This not only shows the message to the user, but instructs the harness to stop running the tests entirely. This is exactly what we want here, as the problem is in the command-line options, and every test script would produce the same error. The result looks like this (the first "Bailout called" line is in red if prove uses color on your terminal): $ make GIT_TEST_OPTS='--verbose --tee' rm -f -r 'test-results' * prove * Bailout called. Further testing stopped: verbose mode forbidden under TAP harness; try --verbose-log FAILED--Further testing stopped: verbose mode forbidden under TAP harness; try --verbose-log Makefile:39: recipe for target 'prove' failed make: *** [prove] Error 255 Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Jeff King	452320f1f5	test-lib: add --verbose-log option The "--verbose" option redirects output from arbitrary test commands to stdout. This is useful for examining the output manually, like: ./t5547-push-quarantine.sh -v \| less But it also means that the output is intermingled with the TAP directives, which can confuse a TAP parser like "prove". This has always been a potential problem, but became an issue recently when one test happened to output the word "ok" on a line by itself, which prove interprets as a test success: $ prove t5547-push-quarantine.sh :: -v t5547-push-quarantine.sh .. 1/? To dest.git * [new branch] HEAD -> master To dest.git ! [remote rejected] reject -> reject (pre-receive hook declined) error: failed to push some refs to 'dest.git' fatal: git cat-file d08c8eba97f4e683ece08654c7c8d2ba0c03b129: bad file t5547-push-quarantine.sh .. Failed -1/4 subtests Test Summary Report ------------------- t5547-push-quarantine.sh (Wstat: 0 Tests: 5 Failed: 0) Parse errors: Tests out of sequence. Found (2) but expected (3) Tests out of sequence. Found (3) but expected (4) Tests out of sequence. Found (4) but expected (5) Bad plan. You planned 4 tests but ran 5. Files=1, Tests=5, 0 wallclock secs ( 0.01 usr + 0.01 sys = 0.02 CPU) Result: FAIL One answer is "if it hurts, don't do it", but that's not quite the whole story. The Travis tests use "--verbose --tee" so that they can get the benefit of prove's parallel options, along with a verbose log in case there is a failure. We just need the verbose output to go to the log, but keep stdout clean. Getting this right turns out to be surprisingly difficult. Here's the progression of alternatives I considered: 1. Add an option to write verbose output to stderr. This is hard to capture, though, because we want each test to have its own log (because they're all run in parallel and the jumbled output would be useless). 2. Add an option to write verbose output to a file in test-results. This works, but the log is missing all of the non-verbose output, which gives context. 3. Like (2), but teach say_color() to additionally output to the log. This mostly works, but misses any output that happens outside of the say() functions (which isn't a lot, but is a potential maintenance headache). 4. Like (2), but make the log file the same as the "--tee" file. That almost works, but now we have two processes opening the same file. That gives us two separate descriptors, each with their own idea of the current position. They'll each start writing at offset 0, and overwrite each other's data. 5. Like (4), but in each case open the file for appending. That atomically positions each write at the end of the file. It's possible we may still get sheared writes between the two processes, but this is already the case when writing to stdout. It's not a problem in practice because the test harness generally waits for snippets to finish before writing the TAP output. We can ignore buffering issues with tee, because POSIX mandates that it does not buffer. Likewise, POSIX specifies "tee -a", so it should be available everywhere. This patch implements option (5), which seems to work well in practice. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Jeff King	925bdc928e	test-lib: handle TEST_OUTPUT_DIRECTORY with spaces We are careful in test_done to handle a results directory with a space in it, but the "--tee" code path does not. Doing: export TEST_OUTPUT_DIRECTORY='/tmp/path with spaces' ./t000-init.sh --tee results in errors. Let's consistently double-quote our path variables so that this works. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Jonathan Tan	63b747ce1a	tests: move test_lazy_prereq JGIT to test-lib.sh This enables JGIT to be used as a prereq in invocations of test_expect_success (and other functions) in other test scripts. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Elia Pinto	4527aa10a6	test-lib.sh: preserve GIT_TRACE_CURL from the environment Turning on this variable can be useful when debugging http tests. It can break a few tests in t5541 if not set to an absolute path but it is not a variable that the user is likely to have enabled accidentally. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Jeff King	5c885c1b53	test-lib: drop PID from test-results/.count Each test run generates a "count" file in t/test-results that stores the number of successful, failed, etc tests. If you run "t1234-foo.sh", that file is named as "t/test-results/t1234-foo-$$.count" The addition of the PID there is serving no purpose, and makes analysis of the count files harder. The presence of the PID dates back to `2d84e9f` (Modify test-lib.sh to output stats to t/test-results/, 2008-06-08), but no reasoning is given there. Looking at the current code, we can see that other files we write to test-results (like .exit and .out) do _not_ have the PID included. So the presence of the PID does not meaningfully allow one to store the results from multiple runs anyway. Moreover, anybody wishing to read the *.count files to aggregate results has to deal with the presence of multiple files for a given test (and figure out which one is the most recent based on their timestamps!). The only consumer of these files is the aggregate.sh script, which arguably gets this wrong. If a test is run multiple times, its counts will appear multiple times in the total (I say arguably only because the desired semantics aren't documented anywhere, but I have trouble seeing how this behavior could be useful). So let's just drop the PID, which fixes aggregate.sh, and will make new features based around the count files easier to write. Note that since the count-file may already exist (when re-running a test), we also switch the "cat" from appending to truncating. The use of append here was pointless in the first place, as we expected to always write to a unique file. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Nguyễn Thái Ngọc Duy	378932d3c3	test-lib.sh: introduce and use $EMPTY_BLOB Similar to $EMPTY_TREE this makes it easier to recognize this special SHA-1 and change hash later. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Nguyễn Thái Ngọc Duy	f9e7d9f8c3	test-lib.sh: introduce and use $EMPTY_TREE This is a special SHA1. Let's keep it at one place, easier to replace later when the hash change comes, easier to recognize. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Jeff King	6b9c38e14c	t0006: skip "far in the future" test when unsigned long is not long enough Git's source code refers to timestamps as unsigned longs. On 32-bit platforms, as well as on Windows, unsigned long is not large enough to capture dates that are "absurdly far in the future". While we can fix this issue properly by replacing unsigned long with a larger type, we want to be a bit more conservative and just skip those tests on the maint track. Signed-off-by: Jeff King <peff@peff.net> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Johannes Schindelin	503e224180	t/test-lib.sh: fix running tests with --valgrind We forgot to adjust this code path after moving the test helpers to t/helper/. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Acked-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Jeff King	d88785e424	test-lib: set BASH_XTRACEFD automatically Passing "-x" to a test script enables the shell's "set -x" tracing, which can help with tracking down the command that is causing a failure. Unfortunately, it can also _cause_ failures in some tests that redirect the stderr of a shell function. Inside the function the shell continues to respect "set -x", and the trace output is collected along with whatever stderr is generated normally by the function. You can see an example of this by running: ./t0040-parse-options.sh -x -i which will fail immediately in the first test, as it expects: test_must_fail some-cmd 2>output.err to leave output.err empty (but with "-x" it has our trace output). Unfortunately there isn't a portable or scalable solution to this. We could teach test_must_fail to disable "set -x", but that doesn't help any of the other functions or subshells. However, we can work around it by pointing the "set -x" output to our descriptor 4, which always points to the original stderr of the test script. Unfortunately this only works for bash, but it's better than nothing (and other shells will just ignore the BASH_XTRACEFD variable). The patch itself is a simple one-liner, but note the caveats in the accompanying comments. Automatic tests for our "-x" option may be a bit too meta (and a pain, because they are bash-specific), but I did confirm that it works correctly both with regular "-x" and with "--verbose-only=1". This works because the latter flips "set -x" off and on for particular tests (if it didn't, we would get tracing for all tests, as going to descriptor 4 effectively circumvents the verbose flag). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago

1 2 3 4 5 ...

490 Commits (f2fffc17dcc2c93d0fddbec8f655ebfab2a822ec)