These variables are user parameters to control how to run the perf
tests. Allow users to do so.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update zip tests to skip some that cannot be handled on platform
unzip.
* rs/zip-tests:
t5003: check if unzip supports symlinks
t5000, t5003: move ZIP tests into their own script
t0024, t5000: use test_lazy_prereq for UNZIP
t0024, t5000: clear variable UNZIP, use GIT_UNZIP instead
InfoZIP's unzip takes default parameters from the environment variable
UNZIP. Unset it in the test library and use GIT_UNZIP for specifying
alternate versions of the unzip command instead.
t0024 wasn't even using variable for the actual extraction. t5000
was, but when setting it to InfoZIP's unzip it would try to extract
from itself (because it treats the contents of $UNZIP as parameters),
which failed of course.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Output from the tests is coloured using "green is okay, yellow is
questionable, red is bad and blue is informative" scheme.
* as/test-tweaks:
tests: paint unexpectedly fixed known breakages in bold red
tests: test the test framework more thoroughly
tests: refactor mechanics of testing in a sub test-lib
tests: change info messages from yellow/brown to cyan
tests: paint skipped tests in blue
tests: paint known breakages in yellow
tests: test number comes first in 'not ok $count - $message'
Change color of unexpectedly fixed known breakages to bold red. An
unexpectedly passing test indicates that the test code is somehow
broken or out of sync with the code it is testing. Either way this is
an error which is potentially as bad as a failing test, and as such is
no longer portrayed as a pass in the output.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that we've adopted a "traffic lights" coloring scheme, yellow is
used for warning messages, so we need to re-color info messages to
something less alarmist. Blue is a universal color for informational
messages; however we are using that for skipped tests in order to
align with the color schemes of other test suites. Therefore we use
cyan which is also blue-ish, but visually distinct from blue.
This was suggested on the list a while ago and no-one raised any
objections:
http://thread.gmane.org/gmane.comp.version-control.git/205675/focus=205966
An earlier iteration of this patch used bold cyan, but the point of
this change is to make them less alarming; let's drop the boldness.
Also paint the message to report skipping the whole thing via
GIT_SKIP_TESTS mechanism in the same color as the "info" color
that is used on the final summary line for the entire script.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Skipped tests indicate incomplete test coverage. Whilst this is not a
test failure or other error, it's still not a complete success.
Other testsuite related software like automake, autotest and prove
seem to use blue for skipped tests, so let's follow suit.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Yellow seems a more appropriate color than bold green when
considering the universal traffic lights coloring scheme, where
green conveys the impression that everything's OK, and amber that
something's not quite right.
Likewise, change the color of the summarized total number of known
breakages from bold red to the same yellow to be less alarmist and
more consistent with the above.
An earlier version of this patch used bold yellow but because these
are all long-known failures, reminding them to developers in bold
over and over does not help encouraging them to take a look at them
very much. This iteration paints them in plain yellow instead to
make them less distracting.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old output to say "not ok - 1 messsage" was working by accident
only because the test numbers are optional in TAP.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
New remote helper for hg.
* fc/remote-hg: (22 commits)
remote-hg: fix for older versions of python
remote-hg: fix for files with spaces
remote-hg: avoid bad refs
remote-hg: try the 'tip' if no checkout present
remote-hg: fix compatibility with older versions of hg
remote-hg: add missing config for basic tests
remote-hg: the author email can be null
remote-hg: add option to not track branches
remote-hg: add extra author test
remote-hg: add tests to compare with hg-git
remote-hg: add bidirectional tests
test-lib: avoid full path to store test results
remote-hg: add basic tests
remote-hg: fake bookmark when there's none
remote-hg: add compat for hg-git author fixes
remote-hg: add support for hg-git compat mode
remote-hg: match hg merge behavior
remote-hg: make sure the encoding is correct
remote-hg: add support to push URLs
remote-hg: add support for remote pushing
...
The "say" function in the test scaffolding incorrectly allowed
"echo" to interpret "\a" as if it were a C-string asking for a BEL
output.
* jc/test-say-color-avoid-echo-escape:
test-lib: Fix say_color () not to interpret \a\b\c in the message
t7502 checks the behavior of commit when we can and cannot
determine a valid committer ident. Let's move that into
test-lib as a lazy prerequisite so other scripts can use it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
No reason to use the full path in case this is used externally.
Otherwise we might get errors such as:
./test-lib.sh: line 394: /home/bob/dev/git/t/test-results//home/bob/dev/git/contrib/remote-hg/test-2894.counts: No such file or directory
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Recent nd/wildmatch series was the first to reveal this ancient bug
in the test scaffolding.
* jc/test-say-color-avoid-echo-escape:
test-lib: Fix say_color () not to interpret \a\b\c in the message
When running with color disabled (e.g. under prove to produce TAP
output), say_color() helper function is defined to use echo to show
the message. With a message that ends with "\c", echo is allowed to
interpret it as "Do not end the line with LF".
Use printf "%s\n" to emit the message literally.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The malloc checks in tests are currently disabled. Actually evaluate
the variable for turning them off and enable them if it's unset.
Also use this opportunity to give it the more descriptive and
consistent name TEST_NO_MALLOC_CHECK.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Only the first test t0000 in the test suite made sure we have built
Git to be tested; move the check to test-lib so that it applies to
all tests equally.
* rr/test-make-sure-we-have-git:
t/test-lib: make sure Git has already been built
The codepath for handling "--tee" ends up relaunching the test
script under a shell, and that one has to be a Bourne. But we
incorrectly used $SHELL, which could be a non-Bourne (e.g. zsh or
csh); we have the Makefile variable $SHELL_PATH for exactly that,
so use it instead.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When tests were run without building git, they stopped with:
.: 54: Can't open /path/to/git/source/t/../GIT-BUILD-OPTIONS
Move the check that makes sure that git has already been built from
t0000 to test-lib, so that any test will do so before it runs.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The most important in this change is to avoid affecting anything
when test-lib is used from perf-lib. It also limits the effect of
the MALLOC_CHECK only to what is run inside the actual test, and
uses a fixed MALLOC_PERTURB_ in order to avoid hurting repeatability
of the tests.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recent versions of Linux libc (later than 5.4.23) and glibc (2.x)
include a malloc() implementation which is tunable via environment
variables. When MALLOC_CHECK_ is set, a special (less efficient)
implementation is used which is designed to be tolerant against
simple errors, such as double calls of free() with the same argument,
or overruns of a single byte (off-by-one bugs). When MALLOC_CHECK_
is set to 3, a diagnostic message is printed on stderr
and the program is aborted.
Setting the MALLOC_PERTURB_ environment variable causes the malloc
functions in libc to return memory which has been wiped and clear
memory when it is returned.
Of course this does not affect calloc which always does clear the memory.
The reason for this exercise is, of course, to find code which uses
memory returned by malloc without initializing it and code which uses
code after it is freed. valgrind can do this but it's costly to run.
The MALLOC_PERTURB_ exchanges the ability to detect problems in 100%
of the cases with speed.
The byte value used to initialize values returned by malloc is the byte
value of the environment value. The value used to clear memory is the
bitwise inverse. Setting MALLOC_PERTURB_ to zero disables the feature.
This technique can find hard to detect bugs.
It is therefore suggested to always use this flag (at least temporarily)
when testing out code or a new distribution.
But the test suite can use also valgrind(memcheck) via 'make valgrind'
or 'make GIT_TEST_OPTS="--valgrind"'.
Memcheck wraps client calls to malloc(), and puts a "red zone" on
each end of each block in order to detect access overruns.
Memcheck already detects double free() (up to the limit of the buffer
which remembers pending free()). Thus memcheck subsumes all the
documented coverage of MALLOC_CHECK_.
If MALLOC_CHECK_ is set non-zero when running memcheck, then the
overruns that might be detected by MALLOC_CHECK_ would be overruns
on the wrapped blocks which include the red zones. Thus MALLOC_CHECK_
would be checking memcheck, and not the client. This is not useful,
and actually is wasteful. The only possible [documented] advantage
of using MALLOC_CHECK_ and memcheck together, would be if MALLOC_CHECK_
detected duplicate free() in more cases than memcheck because memcheck's
buffer is too small.
Therefore we don't use MALLOC_CHECK_ and valgrind(memcheck) at the
same time.
Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rj/tap-fix:
test-lib.sh: Suppress the "passed all ..." message if no tests run
test-lib.sh: Add check for invalid use of 'skip_all' facility
test-lib.sh: Fix some shell coding style violations
t4016-*.sh: Skip all tests rather than each test
t3902-*.sh: Skip all tests rather than each test
t3300-*.sh: Fix a TAP parse error
If a test script issues a test_done without executing any tests, for
example when using the 'skip_all' facility, the output looks something
like this:
$ ./t9159-git-svn-no-parent-mergeinfo.sh
# passed all 0 test(s)
1..0 # SKIP skipping git svn tests, svn not found
$
The "passed all 0 test(s)" comment line, while correct, looks a little
strange. Add a check to suppress this message if no tests have actually
been run.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'skip_all' facility cannot be used after one or more tests
have been executed using (for example) 'test_expect_success'.
To do so results in invalid TAP output, which leads to 'prove'
complaining of "Parse errors: No plan found in TAP output".
Add a check for such invalid usage and abort the test with an
error message to alert the test author.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
UTF8 behaviour of the filesystem (conversion from nfd to nfc) plays a
role in several tests and is tested in several tests. Therefore, move
the test from t0050 into the test lib and use the prerequisite in t0050.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Case insensitivity plays a role in several tests and is tested in several
tests. Therefore, move the test from t003 into the test lib and use the
prerequisite in t0003.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test prerequisite mechanism is a useful way to allow some tests
in a test script to be skipped in environments that do not support
certain features (e.g. it is pointless to attempt checking how well
symbolic links are handled by Git on filesystems that do not support
them). It is OK for commonly used prerequisites to be always tested
during start-up of a test script by having a codeblock that tests a
feature and calls test_set_prereq, but for an uncommon feature,
forcing 90% of scripts to pay the same probing overhead for
prerequisite they do not care about is wasteful.
Introduce a mechanism to probe the prerequiste lazily. Changes are:
- test_lazy_prereq () function, which takes the name of the
prerequisite it probes and the script to probe for it, is
added. This only registers the name of the prerequiste that can
be lazily probed and the script to eval (without running).
- test_have_prereq() function (which is used by test_expect_success
and also can be called directly by test scripts) learns to look
at the list of prerequisites that can be lazily probed, and the
prerequisites that have already been probed that way. When asked
for a prerequiste that can be but haven't been probed, the script
registered with an earlier call to test_lazy_prereq is evaluated
and the prerequisite is set.
- test_run_lazy_prereq_() function is a helper to run the probe
script with the same kind of sandbox as regular tests, helped by
Jeff King.
Update the codeblock to probe and set SYMLINKS prerequisite using
the new mechanism as an example.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reorders t/test-lib.sh so that we dot-source GIT-BUILD-OPTIONS that
records the shell and Perl the user told us to use with Git a lot
early, so that test-lib.sh script itself can use "$PERL_PATH" in
one of its early operations.
* jc/test-lib-source-build-options-early:
test-lib: reorder and include GIT-BUILD-OPTIONS a lot earlier
Finishing touches to the XDG support (new feature for 1.7.12) and
tests.
* mm/config-xdg:
t1306: check that XDG_CONFIG_HOME works
ignore: make sure we have an xdg path before using it
attr: make sure we have an xdg path before using it
test-lib.sh: unset XDG_CONFIG_HOME
Now that git respects XDG_CONFIG_HOME for some lookups, we
must be sure to cleanse the test environment. Otherwise, the
user's XDG_CONFIG_HOME could influence the test results.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This dot-sources GIT-BUILD-OPTIONS a lot earlier in test-lib.sh so
that its use of "perl" can use "$PERL_PATH" to choose the version of
Perl the user told us is suitable for our use.
This is iffy; I didn't check it very carefully, and I would not be
surprised if there are subtle breakages.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most notably, t4031 creates a small shell script that invokes perl
and we want to use "$PERL_PATH" to name the version of Perl suitable
for our use, read from GIT-BUILD-OPTS. The test would fail when it
is directly run in t/ directory from the shell or "make" is run in t/
directory.
This problem was hidden from "make test" run in the top-level
directory, because its Makefile exports PERL_PATH.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A broken shell may not let us set an environment value to an arbitrary
value, interfering with some of the tests. Introduce a test prerequisite
so that we can skip some tests on such a platform.
By Zbigniew Jędrzejewski-Szmek
* zj/mksh-columns-breakage:
test-lib: skip test with COLUMNS=1 under mksh
mksh does not allow $COLUMNS to be set below 12. mksh(1) says that
$COLUMNS is "always set, defaults to 80, unless the value as reported
by stty(1) is non-zero and sane enough". This applies also to setting
it directly for one command:
$ COLUMNS=10 python -c 'import os; print os.environ["COLUMNS"]'
98
Add a test prerequisite by checking if we can set COLUMNS=1, to allow
us to skip tests that needs it.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
$COLUMNS must be unset to not interfere with the tests. The tests
already ignore the terminal size because output is redirected to a
file, but COLUMNS overrides terminal size detection and changes the
test output away from the standard 80.
Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Update draft release notes to 1.7.9.3 for the last time
http.proxy: also mention https_proxy and all_proxy
t0300: work around bug in dash 0.5.6
t5512 (ls-remote): modernize style
tests: fix spurious error when run directly with Solaris /usr/xpg4/bin/sh
If any test script is run directly with Solaris 10 /usr/xpg4/bin/sh or
/bin/ksh, it fails spuriously with a message like:
t0000-basic.sh[31]: unset: bad argument count
This happens because those shells bail out when encountering a call to
"unset" with no arguments, and such unset call could take place in
'test-lib.sh'. Fix that issue, and add a proper comment to ensure we
don't regress in this respect.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This introduces a performance testing framework under t/perf/. It
tries to be as close to the test-lib.sh infrastructure as possible,
and thus should be easy to get used to for git developers.
The following points were considered for the implementation:
1. You usually want to compare arbitrary revisions/build trees against
each other. They may not have the performance test under
consideration, or even the perf-lib.sh infrastructure.
To cope with this, the 'run' script lets you specify arbitrary
build dirs and revisions. It even automatically builds the revisions
if it doesn't have them at hand yet.
2. Usually you would not want to run all tests. It would take too
long anyway. The 'run' script lets you specify which tests to run;
or you can also do it manually. There is a Makefile for
discoverability and 'make clean', but it is not meant for
real-world use.
3. Creating test repos from scratch in every test is extremely
time-consuming, and shipping or downloading such large/weird repos
is out of the question.
We leave this decision to the user. Two different sizes of test
repos can be configured, and the scripts just copy one or more of
those (using hardlinks for the object store). By default it tries
to use the build tree's git.git repository.
This is fairly fast and versatile. Using a copy instead of a clone
preserves many properties that the user may want to test for, such
as lots of loose objects, unpacked refs, etc.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This just moves all the user-facing functions to a separate file and
sources that instead.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many of the scripts in the test suite write small helper
shell scripts to disk. It's best if these shell scripts
start with "#!$SHELL_PATH" rather than "#!/bin/sh", because
/bin/sh on some platforms is too buggy to be used.
However, it can be cumbersome to expand $SHELL_PATH, because
the usual recipe for writing a script is:
cat >foo.sh <<-\EOF
#!/bin/sh
echo my arguments are "$@"
EOF
To expand $SHELL_PATH, you have to either interpolate the
here-doc (which would require quoting "\$@"), or split the
creation into two commands (interpolating the $SHELL_PATH
line, but not the rest of the script). Let's provide a
helper function that makes that less syntactically painful.
While we're at it, this helper can also take care of the
"chmod +x" that typically comes after the creation of such a
script, saving the caller a line.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Traditionally, a cleanly resolved merge was committed by "git merge" using
the auto-generated merge commit log message without invoking the editor.
After 5 years of use in the field, it turns out that people perform too
many unjustified merges of the upstream history into their topic branches.
These merges are not just useless, but they are often not explained well,
and making the end result unreadable when it gets time for merging their
history back to their upstream.
Earlier we added the "--edit" option to the command, so that people can
edit the log message to explain and justify their merge commits. Let's
take it one step further and spawn the editor by default when we are in an
interactive session (i.e. the standard input and the standard output are
pointing at the same tty device).
There may be existing scripts that leave the standard input and the
standard output of the "git merge" connected to whatever environment the
scripts were started, and such invocation might trigger the above
"interactive session" heuristics. GIT_MERGE_AUTOEDIT environment variable
can be set to "no" at the beginning of such scripts to use the historical
behaviour while the script runs.
Note that this backward compatibility is meant only for scripts, and we
deliberately do *not* support "merge.edit = yes/no/auto" configuration
option to allow people to keep the historical behaviour.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 781f76b15 (test-lib: redirect stdin of tests) you can't simply put a
"bash &&" into a test for debugging purposes anymore. Instead you'll have
to use "bash <&6 >&3 2>&4".
As that invocation is not that easy to remember add the test_pause
convenience function. It invokes "$SHELL_PATH" to provide a sane shell
for the user.
This function also checks if the -v flag is given and will error out if
that is not the case instead of letting the test hang until ^D is pressed.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We want to run tests in a predictable, sterile environment
so we can get repeatable results. They should take as
little input as possible from the environment outside the
test script. We already sanitize environment variables, but
leave stdin untouched. This means that scripts can
accidentally be impacted by content on stdin, or whether
stdin isatty().
Furthermore, scripts reading from stdin can be annoying to
outer loops which care about their stdin offset, like:
while read sha1; do
make test
done
A test which accidentally reads stdin would soak up all of
the rest of the input intended for the outer shell loop.
Let's redirect stdin from /dev/null, which solves both
of these problems. It won't detect tests accidentally
reading from stdin, but since doing so now gives a
deterministic result, we don't need to consider that an
error.
We'll also leave file descriptor 6 as a link to the original
stdin. Tests shouldn't need to look at this, but it can be
convenient for inserting interactive commands while
debugging tests (e.g., you could insert "bash <&6 >&3 2>&4"
to run interactive commands in the environment of the test
script).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The point of test_config is to simultaneously set a config
variable and register its cleanup handler, like:
test_config core.foo bar
However, it stupidly assumes that $1 contained the name of
the variable, which means it won't work for:
test_config --global core.foo bar
We could try to parse the command-line ourselves and figure
out which parts need to be fed to test_unconfig. But since
this is likely the most common variant, it's much simpler
and less error-prone to simply add a new function.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the skeleton implementation of i18n in Git to one that can show
localized strings to users for our C, Shell and Perl programs using
either GNU libintl or the Solaris gettext implementation.
This new internationalization support is enabled by default. If
gettext isn't available, or if Git is compiled with
NO_GETTEXT=YesPlease, Git falls back on its current behavior of
showing interface messages in English. When using the autoconf script
we'll auto-detect if the gettext libraries are installed and act
appropriately.
This change is somewhat large because as well as adding a C, Shell and
Perl i18n interface we're adding a lot of tests for them, and for
those tests to work we need a skeleton PO file to actually test
translations. A minimal Icelandic translation is included for this
purpose. Icelandic includes multi-byte characters which makes it easy
to test various edge cases, and it's a language I happen to
understand.
The rest of the commit message goes into detail about various
sub-parts of this commit.
= Installation
Gettext .mo files will be installed and looked for in the standard
$(prefix)/share/locale path. GIT_TEXTDOMAINDIR can also be set to
override that, but that's only intended to be used to test Git itself.
= Perl
Perl code that's to be localized should use the new Git::I18n
module. It imports a __ function into the caller's package by default.
Instead of using the high level Locale::TextDomain interface I've
opted to use the low-level (equivalent to the C interface)
Locale::Messages module, which Locale::TextDomain itself uses.
Locale::TextDomain does a lot of redundant work we don't need, and
some of it would potentially introduce bugs. It tries to set the
$TEXTDOMAIN based on package of the caller, and has its own
hardcoded paths where it'll search for messages.
I found it easier just to completely avoid it rather than try to
circumvent its behavior. In any case, this is an issue wholly
internal Git::I18N. Its guts can be changed later if that's deemed
necessary.
See <AANLkTilYD_NyIZMyj9dHtVk-ylVBfvyxpCC7982LWnVd@mail.gmail.com> for
a further elaboration on this topic.
= Shell
Shell code that's to be localized should use the git-sh-i18n
library. It's basically just a wrapper for the system's gettext.sh.
If gettext.sh isn't available we'll fall back on gettext(1) if it's
available. The latter is available without the former on Solaris,
which has its own non-GNU gettext implementation. We also need to
emulate eval_gettext() there.
If neither are present we'll use a dumb printf(1) fall-through
wrapper.
= About libcharset.h and langinfo.h
We use libcharset to query the character set of the current locale if
it's available. I.e. we'll use it instead of nl_langinfo if
HAVE_LIBCHARSET_H is set.
The GNU gettext manual recommends using langinfo.h's
nl_langinfo(CODESET) to acquire the current character set, but on
systems that have libcharset.h's locale_charset() using the latter is
either saner, or the only option on those systems.
GNU and Solaris have a nl_langinfo(CODESET), FreeBSD can use either,
but MinGW and some others need to use libcharset.h's locale_charset()
instead.
=Credits
This patch is based on work by Jeff Epler <jepler@unpythonic.net> who
did the initial Makefile / C work, and a lot of comments from the Git
mailing list, including Jonathan Nieder, Jakub Narebski, Johannes
Sixt, Erik Faye-Lund, Peter Krefting, Junio C Hamano, Thomas Rast and
others.
[jc: squashed a small Makefile fix from Ramsay]
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since bc7a96a (mergetool--lib: Refactor tools into separate files,
2011-08-18) the mergetools and difftools related tests fail under
--valgrind because the mergetools/* scriptlets are not in the exec
path.
For now, symlink the mergetools subdir into the t/valgrind/bin
directory as a whole, since it does not contain anything of interest
to the valgrind wrappers.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/color-and-pager:
want_color: automatically fallback to color.ui
diff: don't load color config in plumbing
config: refactor get_colorbool function
color: delay auto-color decision until point of use
git_config_colorbool: refactor stdout_is_tty handling
diff: refactor COLOR_DIFF from a flag into an int
setup_pager: set GIT_PAGER_IN_USE
t7006: use test_config helpers
test-lib: add helper functions for config
t7006: modernize calls to unset
Conflicts:
builtin/commit.c
parse-options.c
There are a few common tasks when working with configuration
variables in tests; this patch aims to make them a little
easier to write and less error-prone.
When setting a variable, you should typically make sure to
clean it up after the test is finished, so as not to pollute
other tests. Like:
test_when_finished 'git config --unset foo.bar' &&
git config foo.bar baz
This patch lets you just write:
test_config foo.bar baz
When clearing a variable that does not exist, git-config
will report a specific non-zero error code. Meaning that
tests which call "git config --unset" often either rely on
the prior tests having actually set it, or must use
test_might_fail. With this patch, the previous:
test_might_fail git config --unset foo.bar
becomes:
test_unconfig foo.bar
Not only is this easier to type, but it is more robust; it
will correctly detect errors from git-config besides "key
was not set".
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As we seem to need this variable that holds a single LF character
in many places, define it in test-lib.sh and let the test scripts
use it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In olden times, tests would quietly exit the script when they failed
at an inconvenient moment, which was a little disconcerting.
Therefore v0.99.5~24^2~4 (Trapping exit in tests, using return for
errors, 2005-08-10) switched to an idiom of using "return" instead,
wrapping evaluation of test code in a function to make that safe:
test_run_ () {
eval >&3 2>&4 "$1"
eval_ret="$?"
return 0
}
Years later, the implementation of test_when_finished (v1.7.1.1~95,
2010-05-02) and v1.7.2-rc2~1^2~13 (test-lib: output a newline before
"ok" under a TAP harness, 2010-06-24) took advantage of test_run_ as a
place to put code shared by all test assertion functions, without
paying attention to the function's former purpose:
test_run_ () {
...
eval >&3 2>&4 "$1"
eval_ret=$?
if should run cleanup
then
eval >&3 2>&4 "$test_cleanup"
fi
if TAP format requires a newline here
then
echo
fi
return 0
}
That means cleanup commands and the newline to put TAP output at
column 0 are skipped when tests use "return" to fail early. Fix it by
introducing a test_eval_ function to catch the "return", with a
comment explaining the new function's purpose for the next person who
might touch this code.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As v0.99.5~24^2~4 (Trapping exit in tests, using return for errors,
2005-08-10) explains, callers to test_run_ (such as test_expect_code)
used to check the result from eval and the return value separately so
tests that fail early could be distinguished from tests that completed
normally with successful (nonzero) status. Eventually tests that
succeed with nonzero status were phased out (see v1.7.4-rc0~65^2~19,
2010-10-03 and especially v1.5.5-rc0~271, 2008-02-01) but the weird
two-return-value calling convention lives on.
Let's get rid of it. The new rule: test_run_ succeeds (returns 0)
if and only if the test succeeded.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some tests try to be too careful about cleaning themselves up and
do
test_expect_success description '
set-up some test refs and/or configuration &&
test_when_finished "revert the above changes" &&
the real test
'
Which is nice to make sure that a potential failure would not have
unexpected interaction with the next test. This however interferes when
"the real test" fails and we want to see what is going on, by running the
test with --immediate mode and descending into its trash directory after
the test stops. The precondition to run the real test and cause it to fail
is all gone after the clean-up procedure defined by test_when_finished is
done.
Update test_run_ which is the workhorse of running a test script
called from test_expect_success and test_expect_failure, so that we do not
run clean-up script defined with test_when_finished when a test that is
expected to succeed fails under the --immediate mode.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Jeff King <peff@peff.net>
When we run tests under valgrind, we symlink anything
executable that starts with git-* or test-* into a special
valgrind bin directory, and then make that our
GIT_EXEC_PATH.
However, shell libraries like git-sh-setup do not have the
executable bit marked, and did not get symlinked. This
means that any test looking for shell libraries in our
exec-path would fail to find them, even though that is a
fine thing to do when testing against a regular git build
(or in a git install, for that matter).
t2300 demonstrated this problem. The fix is to symlink these
shell libraries directly into the valgrind directory.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ab/i18n-fixup: (24 commits)
i18n: use test_i18n{cmp,grep} in t7600, t7607, t7611 and t7811
i18n: use test_i18n{grep,cmp} in t7508
i18n: use test_i18ngrep in t7506
i18n: use test_i18ngrep and test_i18ncmp in t7502
i18n: use test_i18ngrep in t7501
i18n: use test_i18ncmp in t7500
i18n: use test_i18ngrep in t7201
i18n: use test_i18ncmp and test_i18ngrep in t7102 and t7110
i18n: use test_i18ncmp and test_i18ngrep in t5541, t6040, t6120, t7004, t7012 and t7060
i18n: use test_i18ncmp and test_i18ngrep in t3700, t4001 and t4014
i18n: use test_i18ncmp and test_i18ngrep in t3203, t3501 and t3507
i18n: use test_i18ngrep in t2020, t2204, t3030, and t3200
i18n: use test_i18ngrep in lib-httpd and t2019
i18n: do not overuse C_LOCALE_OUTPUT (grep)
i18n: use test_i18ncmp in t1200 and t2200
i18n: .git file is not a human readable message (t5601)
i18n: do not overuse C_LOCALE_OUTPUT
i18n: mark init-db messages for translation
i18n: mark checkout plural warning for translation
i18n: mark checkout --detach messages for translation
...
* mk/grep-pcre:
git-grep: Fix problems with recently added tests
git-grep: Update tests (mainly for -P)
Makefile: Pass USE_LIBPCRE down in GIT-BUILD-OPTIONS
git-grep: update tests now regexp type is "last one wins"
git-grep: do not die upon -F/-P when grep.extendedRegexp is set.
git-grep: Bail out when -P is used with -F or -E
grep: Add basic tests
configure: Check for libpcre
git-grep: Learn PCRE
grep: Extract compile_regexp_failed() from compile_regexp()
grep: Fix a typo in a comment
grep: Put calls to fixmatch() and regmatch() into patmatch()
contrib/completion: --line-number to git grep
Documentation: Add --line-number to git-grep synopsis
* jn/userdiff-perl-updates:
userdiff/perl: tighten BEGIN/END block pattern to reject here-doc delimiters
tests: make test_expect_code quieter on success
userdiff/perl: catch sub with brace on second line
userdiff/perl: match full line of POD headers
userdiff/perl: anchor "sub" and "package" patterns on the left
t4018 (funcname patterns): minor cleanups
t4018 (funcname patterns): make configuration easier to track
t4018 (funcname patterns): make .gitattributes state easier to track
A command exiting with the expected status is not particularly
notable.
While the indication of progress might be useful when tracking down
where in a test a failure has happened, the same applies to most other
test helpers, which are quiet about success, so this single helper's
output stands out in an unpleasant way. An alternative method for
showing progress information might to invent a --progress option that
runs tests with "set -x", or until that is available, to run tests
using commands like
prove -v -j2 --shuffle --exec='sh -x' t2202-add-addremove.sh
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/fix-diff-files-unmerged:
diff-files: show unmerged entries correctly
diff: remove often unused parameters from diff_unmerge()
diff.c: return filepair from diff_unmerge()
test: use $_z40 from test-lib
This modest patch adds simple tests for git grep -P/--perl-regexp and
its interoperation with -i and -w.
Tests are only enabled when prerequisite LIBPCRE is defined (it's
automatically set based on USE_LIBPCRE in test-lib.sh).
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/fix-diff-files-unmerged:
diff-files: show unmerged entries correctly
diff: remove often unused parameters from diff_unmerge()
diff.c: return filepair from diff_unmerge()
test: use $_z40 from test-lib
* ab/i18n-fixup: (24 commits)
i18n: use test_i18n{cmp,grep} in t7600, t7607, t7611 and t7811
i18n: use test_i18n{grep,cmp} in t7508
i18n: use test_i18ngrep in t7506
i18n: use test_i18ngrep and test_i18ncmp in t7502
i18n: use test_i18ngrep in t7501
i18n: use test_i18ncmp in t7500
i18n: use test_i18ngrep in t7201
i18n: use test_i18ncmp and test_i18ngrep in t7102 and t7110
i18n: use test_i18ncmp and test_i18ngrep in t5541, t6040, t6120, t7004, t7012 and t7060
i18n: use test_i18ncmp and test_i18ngrep in t3700, t4001 and t4014
i18n: use test_i18ncmp and test_i18ngrep in t3203, t3501 and t3507
i18n: use test_i18ngrep in t2020, t2204, t3030, and t3200
i18n: use test_i18ngrep in lib-httpd and t2019
i18n: do not overuse C_LOCALE_OUTPUT (grep)
i18n: use test_i18ncmp in t1200 and t2200
i18n: .git file is not a human readable message (t5601)
i18n: do not overuse C_LOCALE_OUTPUT
i18n: mark init-db messages for translation
i18n: mark checkout plural warning for translation
i18n: mark checkout --detach messages for translation
...
Apply parameter expansion. Also use here document to save
test results instead of appending each line with ">>".
Signed-off-by: Mathias Lafeldt <misfire@debugon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is no need to duplicate the definition of $_z40 and $_x40 that
test-lib.sh supplies the test scripts.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of skipping the whole test, introduce test_i18ngrep wrapper that
pretends a successful result under GETTEXT_POISON build.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is too coarse-grained way that led to artificial splitting of a
logically single test case into "do" and "check only without poison".
As the majority of check is done by comparing expected and actual output
stored in a file with test_cmp anyway, just introduce test_i18ncmp that
pretends the actual output matched the expected one when gettext-poison
is in effect.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Otherwise the created test repositories will be affected by users ~/.gitconfig.
For example, setting core.logAllrefupdates in users config will make all
calls to "git config --unset core.logAllrefupdates" fail which will break
the first test which uses the statement and expects it to succeed.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In commit 95a1d12e9b ("tests: scrub environment of GIT_* variables") all
environment variables starting with "GIT_" were unset for the tests using
a perl script rather than unsetting them one by one. Only three exceptions
were made to make them work as before: "GIT_TRACE*", "GIT_DEBUG*" and
"GIT_USE_LOOKUP".
Unfortunately some environment variables used by the test framework itself
were not added to the exceptions and thus stopped working when given
before the make command instead of after it. Those are:
- GIT_NOTES_TIMING_TESTS
- GIT_PATCHID_TIMING_TESTS
- GIT_PROVE_OPTS
- GIT_REMOTE_SVN_TEST_BIG_FILES
- GIT_SKIP_TESTS
- GIT_TEST*
- GIT_VALGRIND_OPTIONS
I noticed that when skipping a test the way I was used to suddenly failed:
GIT_SKIP_TESTS='t1234' GIT_TEST_OPTS='--root=/dev/shm' make -j10 test
This should work according to t/README, but didn't anymore, so let's fix
that by adding them to the exception list. And to avoid having a long
regexp put the exceptions in a separate variable using nicer formatting.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks-to: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jn/test-sanitize-git-env:
tests: scrub environment of GIT_* variables
config: drop support for GIT_CONFIG_NOGLOBAL
gitattributes: drop support for GIT_ATTR_NOGLOBAL
tests: suppress system gitattributes
tests: stop worrying about obsolete environment variables
Variables from the inherited environment that are meaningful to git
can break tests in undesirable ways. For example,
GIT_PAGER=more sh t5400-send-pack.sh -v -i
hangs. So unset all environment variables in the GIT_ namespace in
test-lib, with a few exceptions:
- GIT_TRACE* are useful for tracking down bugs exhibited by a failing
test;
- GIT_DEBUG* are GIT_TRACE variables by another name, practically
speaking. They should probably be tweaked to follow the
GIT_TRACE_foo scheme and use trace_printf machinery some time.
- GIT_USE_LOOKUP from v1.5.6-rc0~134^2~1 (sha1-lookup: more memory
efficient search in sorted list of SHA-1, 2007-12-29) is about
trying an alternate implementation strategy rather than changing
semantics and it can be useful to compare performance with and
without it set.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that test-lib sets $HOME to protect against pollution from user
settings, GIT_CONFIG_NOGLOBAL is not needed for use by the test
suite any more. And as luck would have it, a quick code search
reveals no other users in the wild.
This patch does not affect GIT_CONFIG_NOSYSTEM, which is still
needed.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Set GIT_ATTR_NOSYSTEM in test-lib to make tests more reliable in two
ways:
- an invalid GIT_ATTR_NOSYSTEM setting should not cause tests to fail
with "fatal: bad config value for 'GIT_ATTR_NOSYSTEM'".
- /etc/gitattributes should not change the outcome of tests.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After v0.99.7~99 (Retire support for old environment variables,
2005-09-09), there is no more need to unset a stray AUTHOR_NAME
variable that might have entered the test environment.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tweak the GETTEXT_POISON facility so it is activated at run time
instead of compile time. If the GIT_GETTEXT_POISON environment
variable is set, _(msg) will result in gibberish as before; but if the
GIT_GETTEXT_POISON variable is not set, it will return the message for
human-readable output. So the behavior of mistranslated and
untranslated git can be compared without rebuilding git in between.
For simplicity we always set the GIT_GETTEXT_POISON variable in tests.
This does not affect builds without the GETTEXT_POISON compile-time
option set, so non-i18n git will not be slowed down.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a new GETTEXT_POISON compile-time parameter to make _(msg) always
return gibberish. So now you can run
make GETTEXT_POISON=YesPlease
to get a copy of git that functions correctly (one hopes) but produces
output that is in nobody's native language at all.
This is a debugging aid for people who are working on the i18n part of
the system, to make sure that they are not marking plumbing messages
that should never be translated with _().
As new strings get marked for translation, naturally a number of tests
will be broken in this mode. Tests that depend on output from
Porcelain will need to be marked with the new C_LOCALE_OUTPUT test
prerequisite. Newly failing tests that do not depend on output from
Porcelain would be bugs due to messages that should not have been
marked for translation.
Note that the string we're using ("# GETTEXT POISON #") intentionally
starts the pound sign. Some of Git's tests such as
t3404-rebase-interactive.sh rely on interactive editing with a fake
editor, and will needlessly break if the message doesn't start with
something the interactive editor considers a comment.
A future patch will fix fix the underlying cause of that issue by
adding "#" characters to the commit advice automatically.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
rebase -i: clarify in-editor documentation of "exec"
tests: sanitize more git environment variables
fast-import: treat filemodify with empty tree as delete
rebase: give a better error message for bogus branch
rebase: use explicit "--" with checkout
Conflicts:
t/t9300-fast-import.sh
These variables should generally not be set in one's
environment, but they do get set by rebase, which means
doing an interactive rebase like:
pick abcd1234 foo
exec make test
will cause false negatives in the test suite.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rj/test-fixes:
t4135-*.sh: Skip the "backslash" tests on cygwin
t3032-*.sh: Do not strip CR from line-endings while grepping on MinGW
t3032-*.sh: Pass the -b (--binary) option to sed on cygwin
t6038-*.sh: Pass the -b (--binary) option to sed on cygwin
Conflicts:
t/t3032-merge-recursive-options.sh
The BSLASHPSPEC tests (11-13) fail on cygwin, since you can't
create files containing an backslash character in the name.
In order to skip these tests, we simply stop (incorrectly)
asserting the BSLASHPSPEC prerequisite in test-lib.sh.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The tests using the fuzz_conflict helper function (tests 5-6)
fail on cygwin in the same way they used to on MinGW, prior
to commit ca02ad3. The solution is also the same; passing the
-b (--binary) option to sed, using the SED_OPTIONS variable.
We introduce a new prerequisite SED_STRIPS_CR to use in the
conditional initialisation of SED_OPTIONS, rather than MINGW.
The new prerequisite is set in test-lib.sh for both MinGW and
Cygwin.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
POSIX awk seems to explicitly not support hexadecimal escape sequences.
From http://pubs.opengroup.org/onlinepubs/009695399/:
Regular expressions in awk have been extended somewhat...
One sequence that is not supported is hexadecimal value escapes
beginning with '\x'.
This affects the awk on IRIX 6.5, and causes t4015.56 to fail.
Use octal instead.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/push-progress:
push: pass --progress down to git-pack-objects
t5523-push-upstream: test progress messages
t5523-push-upstream: add function to ensure fresh upstream repo
test_terminal: ensure redirections work reliably
test_terminal: catch use without TTY prerequisite
test-lib: allow test code to check the list of declared prerequisites
tests: test terminal output to both stdout and stderr
tests: factor out terminal handling from t7006
Some tests check their output with code like the following:
test "$(git ls-files -u B | wc -l)" -eq 3 || {
echo "BAD: should have left stages for B"
return 1
}
The verbose failure condition is used because test, unlike
diff, does not print any useful information about the
nature of the failure when it fails.
Introduce a test_line_count function to help. If used like
git ls-files -u B >output &&
test_line_count -eq 3 output
it will produce output like
test_line_count: line count for output !-eq 3
100644 b023018cabc396e7692c70bbf5784a93d3f738ab 2 hi.c
100644 45b983be36b73c0788dc9cbcb76cbb80fc7bb057 3 hi.c
on failure.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Enhance the test_decode_color function to handle all common color codes,
including background colors and escapes that contain multiple codes.
This change necessitates changing <WHITE> to <BOLD>, so update t4034
as well.
This change is necessary for the next commit in order to test
background colors properly.
Signed-off-by: Kevin Ballard <kevin@sb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is plumbing to prepare helpers like test_terminal to notice buggy
test scripts that do not declare all of the necessary prerequisites.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code paths for showing commits in "git log" and "git
rev-list --graph" correctly handle embedded NULs by looking
only at the resulting strbuf's length, and never treating it
as a C string. The code path for regular rev-list, however,
used printf("%s"), which resulted in truncated output. This
patch uses fwrite instead, like the --graph code path.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change test_expect_code to be a normal test command instead of a
top-level command.
As a top-level command it would fail in cases like:
test_expect_code 1 'phoney' '
foo && bar && (exit 1)
'
Here the test might incorrectly succeed if "foo" or "bar" happened to
fail with exit status 1. Instead we now do:
test_expect_success 'phoney' '
foo && bar && test_expect_code 1 "(exit 1)"
'
Which will only succeed if "foo" and "bar" return status 0, and "(exit
1)" returns status 1. Note that test_expect_code has been made slightly
noisier, as it reports the exit code it receives even upon success.
Some test code in t0000-basic.sh relied on the old semantics of
test_expect_code to test the test_when_finished command. I've
converted that code to use an external test similar to the TODO test I
added in v1.7.3-rc0~2^2~3.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By default, MSYS grep reads in text-mode and converts CRLF into LF line
endings. For testing HTTP use binary mode (-U) as checking is done for
CR in HTTP headers
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
These two tests fail on msysGit because /dev/null is an alias for nul on
Windows and when reading the value back from git config the alias does
not match the real filename. Also the HOME environment variable has a
unix-style path but git returns a native equivalent path for '~'. As
these are platform-dependent equivalent results it seems simplest to
skip the test entirely.
Moves the NOT_MINGW prereq from t5503 into the test library.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
* jk/test-must-fail-missing:
tests: make test_might_fail fail on missing commands
tests: make test_might_fail more verbose
tests: make test_must_fail fail on missing commands
tests: make test_must_fail more verbose
* ab/test-2: (51 commits)
tests: factor HOME=$(pwd) in test-lib.sh
test-lib: use subshell instead of cd $new && .. && cd $old
tests: simplify "missing PREREQ" message
t/t0000-basic.sh: Run the passing TODO test inside its own test-lib
test-lib: Allow overriding of TEST_DIRECTORY
test-lib: Use "$GIT_BUILD_DIR" instead of "$TEST_DIRECTORY"/../
test-lib: Use $TEST_DIRECTORY or $GIT_BUILD_DIR instead of $(pwd) and ../
test: Introduce $GIT_BUILD_DIR
cvs tests: do not touch test CVS repositories shipped with source
t/t9602-cvsimport-branches-tags.sh: Add a PERL prerequisite
t/t9601-cvsimport-vendor-branch.sh: Add a PERL prerequisite
t/t7105-reset-patch.sh: Add a PERL prerequisite
t/t9001-send-email.sh: convert setup code to tests
t/t9001-send-email.sh: change from skip_all=* to prereq skip
t/t9001-send-email.sh: Remove needless PROG=* assignment
t/t9600-cvsimport.sh: change from skip_all=* to prereq skip
lib-patch-mode tests: change from skip_all=* to prereq skip
t/t3701-add-interactive.sh: change from skip_all=* to prereq skip
tests: Move FILEMODE prerequisite to lib-prereq-FILEMODE.sh
t/Makefile: Create test-results dir for smoke target
...
Conflicts:
t/t6035-merge-dir-to-symlink.sh
The same pattern is used in many tests, and makes it easy for new ones to
rely on $HOME being a trashable, clean, directory.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the test_create_repo code added in v1.2.2~6 to use a subshell
instead of keeping track of the old working directory and cd-ing back
when it's done.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a test has no prerequisites satisfied (the usual case), instead
of "missing THING of THING", just say "missing THING". This does not
affect the output when a test is skipped due to a missing
prerequisites if another prerequisite is satisfied.
For example: instead of
ok 8 # skip notes work (missing EXPENSIVE of EXPENSIVE)
ok 9 # skip notes timing with /usr/bin/time (missing EXPENSIVE of USR_BIN_TIME,EXPENSIVE)
write
ok 8 # skip notes work (missing EXPENSIVE)
ok 9 # skip notes timing with /usr/bin/time (missing EXPENSIVE of USR_BIN_TIME,EXPENSIVE)
Cc: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tests that test the test-lib.sh itself need to be executed in the
dynamically created trash directory, so we can't assume
$TEST_DIRECTORY is ../ for those.
As a side benefit this change also makes it easy for us to move the
t/*.sh tests into subdirectories if we ever want to do that.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change code that used $TEST_DIRECTORY/.. to use $GIT_BUILD_DIR
instead, the two are equivalent, but the latter is easier to read.
This required moving the assignment od GIT_BUILD_DIR to earlier in the
test-lib.sh file.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the redundant calls to $(pwd) to use $TEST_DIRECTORY
instead. None of these were being executed after we cd'd somewhere
else so they weren't actually needed.
This also makes it easier to add support for overriding the test
library location and run tests in a different directory than t/.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce a new variable $GIT_BUILD_DIR which can be used to locate
data that resides under the build directory, and use that instead.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Detect and report hard-to-notice spelling mistakes like
test_might_fail "git config --unset whatever"
(the extra quotes prevent the shell from running git as intended;
instead, the shell looks for a "git config --unset whatever" file).
Cc: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Let test_might_fail say something about its failures for consistency
with test_must_fail.
Cc: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The point of it is to run a command that produces failure. A
missing command is more likely an error in the test script
(e.g., using 'test_must_fail "command with arguments"', or
relying on a missing command).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because test_must_fail fails when a command succeeds, the
command frequently does not produce any output (since, after
all, it thought it was succeeding). So let's have
test_must_fail itself report that a problem occurred.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mm/rebase-i-exec:
git-rebase--interactive.sh: use printf instead of echo to print commit message
git-rebase--interactive.sh: rework skip_unnecessary_picks
test-lib: user-friendly alternatives to test [-d|-f|-e]
rebase -i: add exec command to launch a shell command
Conflicts:
git-rebase--interactive.sh
t/t3404-rebase-interactive.sh
The support for multiple test prerequisites added by me in "test-lib:
Add support for multiple test prerequisites" was broken.
The for iterated over each prerequisite and returned true/false within
a case statement, but since it missed a return statement only the last
prerequisite in the list of prerequisites was ever considered, the
rest were ignored.
Fix that by changing the test_have_prereq code to something less
clever that keeps a count of the total prereqs and the ones we have
and compares the count at the end.
This comes with the added advantage that it's easy to list the missing
prerequisites in the test output, implement that while I'm at it.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some tests depend on not being able to write to files after chmod
-w. This doesn't work when running the tests as root.
Change test-lib.sh to test if this works, and if so it sets a new
SANITY test prerequisite. The tests that use this previously failed
when run under root.
There was already a test for this in t3600-rm.sh, added by Junio C
Hamano in 2283645 in 2006. That check now uses the new SANITY
prerequisite.
Some of this was resurrected from the "Tests in Cygwin" thread in May
2009:
http://thread.gmane.org/gmane.comp.version-control.git/116729/focus=118385
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the test output to print needed prerequisites as part of the
TAP. This makes it easy to see at a glance why a test was
skipped. Before:
ok 7 # skip <message>
ok 9 # skip <message>
After:
ok 7 # skip <message> (prereqs: DONTHAVEIT)
ok 9 # skip <message> (prereqs: HAVEIT,DONTHAVEIT)
This'll also be useful for smoke testing output, where the developer
reading the output may not be familiar with the system where tests are
being skipped.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the test_have_prereq function in test-lib.sh to support a
comma-separated list of prerequisites. This is useful for tests that
need e.g. both POSIXPERM and SANITY.
The implementation was stolen from Junio C Hamano and Johannes Sixt,
the tests and documentation were not. See the "Tests in Cygwin" thread
in May 2009 for the originals:
http://thread.gmane.org/gmane.comp.version-control.git/116729/focus=118385http://thread.gmane.org/gmane.comp.version-control.git/116729/focus=118434
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
TAP harnesses don't need to read test-results/*, since they keep track
of the number of passing/failing tests internally. Skip the generation
of these files when HARNESS_ACTIVE is set.
It's now possible to run the Git test suite without writing anything
to the t/ directory at all if you use a TAP harness and the --root
switch:
cd t
sudo mount -t tmpfs none /tmp/memory -o size=300m
prove -j9 ./t[0-9]*.sh :: --root=/tmp/memory
The I/O that the ~500 test-results/* files contributed was very
minimal, but I thought this was worth mentioning.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The helper functions are implemented, documented, and used in a few
places to validate them, but not everywhere to avoid useless code churn.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --no-python option was added to test-lib.sh by Johannes Schindelin
in early 2006 in abb7c7b3. It was later turned into a no-op by Junio C
Hamano in 7cdbff14 the same year.
Over three years is long enough before removing this old wart which
was retained for backwards compatibility. Our tests have been using
NO_PYTHON and "test_have_prereq PYTHON" for a long time now.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Running the tests with --quiet under a TAP harness will always fail,
since a TAP harness always needs actual test output to go along with
the plan that's being emitted.
Change the test-lib.sh to ignore the --quiet option under
HARNESS_ACTIVE to work around this. Then users that have --quiet in
their GIT_TEST_OPTS can run tests under prove(1) without everything
breaking.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Place setup commands in test_expect_success blocks. This makes the
rare event of the setup commands breaking on some platform easier to
diagnose, and more importantly, it visually distinguishes where
each test begins and ends.
Instead of running test -z against the result of "git diff" command
substitution, use "git diff --exit-code", to improve output when
running with the "-v" option.
Use test_cmp in place of "test $(foo) = $(bar)" for similar reasons.
Remove whitespace after the > and < redirection operators for
consistency with other tests.
The order of arguments to test_cmp is "test_cmp expected actual".
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current make target 'aggregate-results' scanned all files matching
test-results/t*-*. Normally these are only the test counts (and the
exit values, which are ignored), but with --tee the suite also dumps
all output. Furthermore, with --verbose t1450 contains several lines
starting with "broken link from ..." which matches the criteria used
by aggregate-results.sh.
Rename the counts output files to *.counts, and only scan those.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make the output TAP compliant for tests skipped on request (GIT_SKIP_TESTS).
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Acked-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
04ece59 (GIT_SKIP_TESTS: allow users to omit tests that are known to break, 2006-12-28)
introduced GIT_SKIP_TESTS, and since then we have had two nested loops
iterating over GIT_SKIP_TESTS with the same loop variable.
Reduce this to one loop.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some tests in the testsuite will emit a line that doesn't end with a
newline, right before we're about to output "ok" or "not ok". This
breaks the TAP output with "Tests out of sequence" errors since a TAP
harness can't understand this:
ok 1 - A test
[some output here]ok 2 - Another test
ok 3 - Yet another test
Work around it by emitting an empty line before we're about to say
"ok" or "not ok", but only if we're running under --verbose and
HARNESS_ACTIVE=1 is set, which'll only be the case when running under
a harnesses like prove(1).
I think it's better to do this than fix each tests by adding `&& echo'
everywhere. More tests might be added that break TAP in the future,
and a human isn't going to look at the extra whitespace, since
HARNESS_ACTIVE=1 always means a harness is reading it.
The tests that had issues were:
t1007, t3410, t3413, t3409, t3414, t3415, t3416, t3412, t3404,
t5407, t7402, t7003, t9001
With this workaround the entire test suite runs without errors under:
prove -j 10 ./t[0-9]*.sh :: --verbose
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before TAP we just ran the Perl test and assumed that it failed if
nothing was printed on STDERR. Continue doing that, but introduce a
`test_external_has_tap' variable which tests can set to indicate that
they're outputting TAP.
If it's set we won't output a test plan, but trust the external test
to do so. That way we can make external tests work with a TAP harness,
but still maintain compatibility with test-lib's own way of tracking
tests through the test-results directory.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
TAP, the Test Anything Protocol, is a simple text-based interface
between testing modules in a test harness. test-lib.sh's output was
already very close to being valid TAP. This change brings it all the
way there. Before:
$ ./t0005-signals.sh
* ok 1: sigchain works
* passed all 1 test(s)
And after:
$ ./t0005-signals.sh
ok 1 - sigchain works
# passed all 1 test(s)
1..1
The advantage of using TAP is that any program that reads the format
(a "test harness") can run the tests. The most popular of these is the
prove(1) utility that comes with Perl. It can run tests in parallel,
display colored output, format the output to console, file, HTML etc.,
and much more. An example:
$ prove ./t0005-signals.sh
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.03 usr 0.00 sys + 0.01 cusr 0.02 csys = 0.06 CPU)
Result: PASS
prove(1) gives you human readable output without being too
verbose. Running the test suite in parallel with `make test -j15`
produces a flood of text. Running them with `prove -j 15 ./t[0-9]*.sh`
makes it easy to follow what's going on.
All this patch does is re-arrange the output a bit so that it conforms
with the TAP spec, everything that the test suite did before continues
to work. That includes aggregating results in t/test-results/, the
--verbose, --debug and other options for tests, and the test color
output.
TAP harnesses ignore everything that they don't know about, so running
the tests with --verbose works:
$ prove ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh .. Terminated
./t0005-signals.sh .. ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.01 cusr 0.01 csys = 0.05 CPU)
Result: PASS
Just supply the -v option to prove itself to get all the verbose
output that it suppresses:
$ prove -v ./t0005-signals.sh :: --verbose --debug
./t0005-signals.sh ..
Initialized empty Git repository in /home/avar/g/git/t/trash directory.t0005-signals/.git/
expecting success:
test-sigchain >actual
case "$?" in
143) true ;; # POSIX w/ SIGTERM=15
3) true ;; # Windows
*) false ;;
esac &&
test_cmp expect actual
Terminated
ok 1 - sigchain works
# passed all 1 test(s)
1..1
ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.01 cusr 0.01 csys = 0.04 CPU)
Result: PASS
As a further example, consider this test script that uses a lot of
test-lib.sh features by Jakub Narebski:
#!/bin/sh
test_description='this is a sample test.
This test is here to see various test outputs.'
. ./test-lib.sh
say 'diagnostic message'
test_expect_success 'true test' 'true'
test_expect_success 'false test' 'false'
test_expect_failure 'true test (todo)' 'true'
test_expect_failure 'false test (todo)' 'false'
test_debug 'echo "debug message"'
test_done
The output of that was previously:
* diagnostic message # yellow
* ok 1: true test
* FAIL 2: false test # bold red
false
* FIXED 3: true test (todo)
* still broken 4: false test (todo) # bold green
* fixed 1 known breakage(s) # green
* still have 1 known breakage(s) # bold red
* failed 1 among remaining 3 test(s) # bold red
But is now:
diagnostic message # yellow
ok 1 - true test
not ok - 2 false test # bold red
# false
ok 3 - true test (todo) # TODO known breakage
not ok 4 - false test (todo) # TODO known breakage # bold green
# fixed 1 known breakage(s) # green
# still have 1 known breakage(s) # bold red
# failed 1 among remaining 3 test(s) # bold red
1..4
All the coloring is preserved when the test is run manually. Under
prove(1) the test performs as expected, even with --debug and
--verbose options:
$ prove ./example.sh :: --debug --verbose
./example.sh .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests
(1 TODO test unexpectedly succeeded)
Test Summary Report
-------------------
./example.sh (Wstat: 256 Tests: 4 Failed: 1)
Failed test: 2
TODO passed: 3
Non-zero exit status: 1
Files=1, Tests=4, 0 wallclock secs ( 0.02 usr 0.00 sys + 0.00 cusr 0.01 csys = 0.03 CPU)
Result: FAIL
The TAP harness itself doesn't get confused by the color output, they
aren't used by test-lib.sh stdout isn't open to a terminal (test -t 1).
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* gv/portable:
test-lib: use DIFF definition from GIT-BUILD-OPTIONS
build: propagate $DIFF to scripts
Makefile: Tru64 portability fix
Makefile: HP-UX 10.20 portability fixes
Makefile: HPUX11 portability fixes
Makefile: SunOS 5.6 portability fix
inline declaration does not work on AIX
Allow disabling "inline"
Some platforms lack socklen_t type
Make NO_{INET_NTOP,INET_PTON} configured independently
Makefile: some platforms do not have hstrerror anywhere
git-compat-util.h: some platforms with mmap() lack MAP_FAILED definition
test_cmp: do not use "diff -u" on platforms that lack one
fixup: do not unconditionally disable "diff -u"
tests: use "test_cmp", not "diff", when verifying the result
Do not use "diff" found on PATH while building and installing
enums: omit trailing comma for portability
Makefile: -lpthread may still be necessary when libc has only pthread stubs
Rewrite dynamic structure initializations to runtime assignment
Makefile: pass CPPFLAGS through to fllow customization
Conflicts:
Makefile
wt-status.h
Otherwise running individual tests from t/ directory may lack the definition
of $DIFF, $GIT_TEST_CMP and friends.
Noticed and initial patch provided by Thomas Rast, alternative solution
suggested by Brandon Casey, which this patch implements.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Thomas Rast <trast@student.ethz.ch>
* jn/gitweb-caching-prep:
gitweb: Move generating page title to separate subroutine
gitweb: Add custom error handler using die_error
gitweb: Use nonlocal jump instead of 'exit' in die_error
gitweb: href(..., -path_info => 0|1)
Export more test-related variables when running external tests
In 3bf7886 (test-lib: Let tests specify commands to be run at end of
test, 2010-05-02), the git test harness learned to run cleanup
commands unconditionally at the end of a test. During each test,
the intended cleanup actions are collected in the test_cleanup variable
and evaluated. That variable looks something like this:
eval_ret=$?; clean_something && (exit "$eval_ret")
eval_ret=$?; clean_something_else && (exit "$eval_ret")
eval_ret=$?; final_cleanup && (exit "$eval_ret")
eval_ret=$?
All cleanup actions are run unconditionally but if one of them fails
it is properly reported through $eval_ret.
On FreeBSD, unfortunately, $? is set at the beginning of an ‘eval’
to 0 instead of the exit status of the previous command. This results
in tests using test_expect_code appearing to fail and all others
appearing to pass, unless their cleanup fails. Avoid the problem by
setting eval_ret before the ‘eval’ begins.
Thanks to Jeff King for the explanation.
Cc: Jeff King <peff@peff.net>
Cc: Johannes Sixt <j6t@kdbg.org>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Certain actions can imply that if the test fails early, recovery from
within other tests is too much to expect:
- creating unwritable directories, like the EACCESS test in t0001-init
- setting unusual configuration, like user.signingkey in t7004-tag
- crashing and leaving the index lock held, like t3600-rm once did
Some test scripts work around this by running cleanup actions outside
the supervision of the test harness, with the unfortunate consequence
that those commands are not appropriately echoed and their output not
suppressed. Others explicitly save exit status, clean up, and then
reset the exit status within the tests, which has excellent behavior
but makes the tests hard to read. Still others ignore the problem.
Allow tests a fourth option: by calling this function, tests can
stack up commands they would like to be run to clean up.
Commands passed to test_when_finished during a test are
unconditionally run in the test environment immediately before the
test is completed, in last-in-first-out order. If some cleanup
command fails, then the other cleanup commands are still run before
the failure is reported and the test script allowed to continue.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Dear Junio,
this is a resend of relicensing patch for test suite library, which
was initially sent by Carl Worth. Since the time you sent me acks for
this patch collected by you, I collected 8 additional acks as is
documented at
https://git.wiki.kernel.org/index.php/Test-lib_reclicensing. There are
still three contributors missing: Bert Wesarg, Stephan Beyer and Bryan
Donlan. The contributions of first two are clearly not copyrightable.
I'm not sure about the copyrightability of Bryan Donlan's
contributions (git log -p --author='Bryan Donlan' t/test-lib.sh).
Carl told me that in your ack collection process you missed only three
acks. So I wonder whether you already did some analysis of which
contributions are copyrightable. If so, are the missing acks in the
list bellow?
Thanks
Michal
8<--------8<--------8<--------
This file has had no explicit license information noted in it, but
has clearly been created and modified according to the terms of GPLv2
as with the rest of the git code base.
The purpose of relicensing is to allow other GPLv3+ projects (in
particular, the notmuch project: http://notmuchmail.org) to use this
same test-suite structure and to contribute changes back as well.
Signed-off-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
Acked-by: Alex Riesen <raa.lkml@gmail.com>
Acked-by: Brandon Casey <drafnel@gmail.com>
Acked-by: Clemens Buchacher <drizzd@aon.at>
Acked-by: David Reiss <dreiss@facebook.com>
Acked-by: Emil Sit <sit@emilsit.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
Acked-by: Fredrik Kuivinen <frekui@gmail.com>
Acked-by: Gerrit Pape <pape@smarden.org>
Acked-by: Christian Couder <chriscool@tuxfamily.org>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Acked-by: Johan Herland <johan@herland.net>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Josh Triplett <josh@joshtriplett.org>
Acked-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Lea Wiemann <lewiemann@gmail.com>
Acked-by: Markus Heidelberg <markus.heidelberg@web.de>
Acked-by: Martin Waitz <tali@admingilde.org>
Acked-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Acked-by: Matthias Lederhofer <matled@gmx.net>
Acked-by: Michael J Gruber <git@drmicha.warpmail.net>
Acked-by: Michele Ballabio <barra_cuda@katamail.com>
Acked-by: Miklos Vajna <vmiklos@frugalware.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Acked-by: Pavel Roskin <proski@gnu.org>
Acked-by: Petr Baudis <pasky@ucw.cz>
Acked-by: Pierre Habouzit <madcoder@debian.org>
Acked-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Stephen Boyd <bebarino@gmail.com>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Acked-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add exporting TEST_DIRECTORY and TRASH_DIRECTORY to test_external, for
external tests to be able to find test script (and git sources), and
to find trash directory (usually with test repository in it).
Add also exporting GIT_TEST_LONG, so that external test can skip
time-intensive tests unless test is invoked with `--long' option.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most of these tests are removing files, environment variables, and
configuration that might interfere outside the test. Putting these
clean-up commands in the test (in the same spirit as v1.7.1-rc0~59,
2010-03-20) means that errors during setup will be caught quickly and
non-error text will be suppressed without -v.
While at it, apply some other minor fixes:
- do not rely on the shell to export variables defined with the same
command as a function call
- avoid whitespace immediately after the > redirection operator, for
consistency with the style of other tests
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tr/notes-display:
git-notes(1): add a section about the meaning of history
notes: track whether notes_trees were changed at all
notes: add shorthand --ref to override GIT_NOTES_REF
commit --amend: copy notes to the new commit
rebase: support automatic notes copying
notes: implement helpers needed for note copying during rewrite
notes: implement 'git notes copy --stdin'
rebase -i: invoke post-rewrite hook
rebase: invoke post-rewrite hook
commit --amend: invoke post-rewrite hook
Documentation: document post-rewrite hook
Support showing notes from more than one notes tree
test-lib: unset GIT_NOTES_REF to stop it from influencing tests
Conflicts:
git-am.sh
refs.c
Implement helper functions to load the rewriting config, and to
actually copy the notes. Also document the config.
Secondly, also implement an undocumented --for-rewrite=<cmd> option to
'git notes copy' which is used like --stdin, but also puts the
configuration for <cmd> into effect. It will be needed to support the
copying in git-rebase.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With this patch, you can set notes.displayRef to a glob that points at
your favourite notes refs, e.g.,
[notes]
displayRef = refs/notes/*
Then git-log and friends will show notes from all trees.
Thanks to Junio C Hamano for lots of feedback, which greatly
influenced the design of the entire series and this commit in
particular.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I used to set GREP_OPTIONS to exclude *.orig and *.rej files. But with this
the test t4252-am-options.sh fails because it calls grep with a .rej file:
grep "@@ -1,3 +1,3 @@" file-2.rej
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
append_cr(), remove_cr(), q_to_nul() and q_to_cr() are defined in multiple
tests. Consolidate them into test-lib.sh so we can stop redefining them.
The use of remove_cr() in t0020 to test for a CR is replaced with a new
function has_cr() to accurately reflect what is intended (the output of
remove_cr() was being thrown away).
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/fix-tree-walk:
read-tree --debug-unpack
unpack-trees.c: look ahead in the index
unpack-trees.c: prepare for looking ahead in the index
Aggressive three-way merge: fix D/F case
traverse_trees(): handle D/F conflict case sanely
more D/F conflict tests
tests: move convenience regexp to match object names to test-lib.sh
Conflicts:
builtin-read-tree.c
unpack-trees.c
unpack-trees.h
* mo/bin-wrappers:
INSTALL: document a simpler way to run uninstalled builds
run test suite without dashed git-commands in PATH
build dashless "bin-wrappers" directory similar to installed bindir
* jk/1.7.0-status:
status/commit: do not suggest "reset HEAD <path>" while merging
commit/status: "git add <path>" is not necessarily how to resolve
commit/status: check $GIT_DIR/MERGE_HEAD only once
t7508-status: test all modes with color
t7508-status: status --porcelain ignores relative paths setting
status: reduce duplicated setup code
status: disable color for porcelain format
status -s: obey color.status
builtin-commit: refactor short-status code into wt-status.c
t7508-status.sh: Add tests for status -s
status -s: respect the status.relativePaths option
docs: note that status configuration affects only long format
commit: support alternate status formats
status: add --porcelain output format
status: refactor format option parsing
status: refactor short-mode printing to its own function
status: typo fix in usage
git status: not "commit --dry-run" anymore
git stat -s: short status output
git stat: the beginning of "status that is not a dry-run of commit"
Conflicts:
t/t4034-diff-words.sh
wt-status.c
* sr/vcs-helper:
tests: handle NO_PYTHON setting
builtin-push: don't access freed transport->url
Add Python support library for remote helpers
Basic build infrastructure for Python scripts
Allow helpers to report in "list" command that the ref is unchanged
Fix various memory leaks in transport-helper.c
Allow helper to map private ref names into normal names
Add support for "import" helper command
Allow specifying the remote helper in the url
Add a config option for remotes to specify a foreign vcs
Allow fetch to modify refs
Use a function to determine whether a remote is valid
Allow programs to not depend on remotes having urls
Fix memory leak in helper method for disconnect
Conflicts:
Documentation/git-remote-helpers.txt
Makefile
builtin-ls-remote.c
builtin-push.c
transport-helper.c
Move a useful script function to decode colored output to
text form from t4034 and use it in this test as well.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this, test-lib checks that the git_remote_helpers
directory has been built. However, if we are building
without python, we will not have done anything at all in
that directory, and test-lib's sanity check will fail.
We bump the inclusion of GIT-BUILD-OPTIONS further up in
test-lib; it contains configuration, and as such should be
read before we do any checks (and in this particular case,
we need its value to do our check properly).
Signed-off-by: Jeff King <peff@peff.net>
Looks-fine-to-me-by: Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Only put bin-wrappers in the PATH (not GIT_EXEC_PATH), to emulate the
default installed user environment, and ensure all the programs run
correctly in such an environment. This is now the default, although
it can be overridden with a --with-dashes test option when running
tests.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch introduces parts of a Python package called
"git_remote_helpers" containing the building blocks for
remote helpers written in Python.
No actual remote helpers are part of this patch, this patch only
includes the common basics needed to start writing such helpers.
The patch includes the necessary Makefile additions to build and
install the git_remote_helpers Python package along with the rest of
Git.
This patch is based on Johan Herland's git_remote_cvs patch and
has been improved by the following contributions:
- David Aguilar: Lots of Python coding style fixes
- David Aguilar: DESTDIR support in Makefile
Cc: David Aguilar <davvid@gmail.com>
Cc: Johan Herland <johan@herland.net>
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch adds basic boilerplate support (based on corresponding Perl
sections) for enabling the building and installation Python scripts.
There are currently no Python scripts being built, and when Python
scripts are added in future patches, their building and installation
can be disabled by defining NO_PYTHON.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refuse to use $VISUAL and fall back to $EDITOR if TERM is unset
or set to "dumb". Traditionally, VISUAL is set to a screen
editor and EDITOR to a line-based editor, which should be more
useful in that situation.
vim, for example, is happy to assume a terminal supports ANSI
sequences even if TERM is dumb (e.g., when running from a text
editor like Acme). git already refuses to fall back to vi on a
dumb terminal if GIT_EDITOR, core.editor, VISUAL, and EDITOR are
unset, but without this patch, that check is suppressed by
VISUAL=vi.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some platforms (IRIX 6.5, Solaris 7) do not provide the 'yes' utility.
Currently, some tests, including t7610 and t9001, try to call this program.
Due to the way the tests are structured, the tests still pass even though
this program is missing. Rather than succeeding by chance, let's provide
an implementation of the simple 'yes' utility in shell for all platforms to
use.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The tests generate a large amount of I/O activity creating
and destroying repositories and files. We can improve the
time it takes to run the test suite by creating trash
directories on filesystems with better performance
characteristic, even though we may not want the rest of the
git repository on those filesystems (e.g., because they are
not network connected, or because they are temporary
ramdisks).
For example, on a dual processor system:
$ cd t && time make -j32
real 1m51.562s
user 0m59.260s
sys 1m20.933s
# /dev/shm is tmpfs
$ cd t && time make -j32 GIT_TEST_OPTS="--root=/dev/shm"
real 1m1.484s
user 0m53.555s
sys 1m5.264s
We almost halve the wall clock time, and we utilize the
dual processors much better.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most scripts don't care about the absolute path to the trash
directory. The one exception was t4014 script, which pieced
together $TEST_DIRECTORY and $test itself to get an absolute
directory.
Instead, let's provide a $TRASH_DIRECTORY which specifies
the same thing. This keeps the $test variable internal to
test-lib.sh and paves the way for trash directories in other
locations.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Exit trap should not be removed in case tests require cleanup code. This
is especially important if tests are executed with the --immediate option.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, unknown options would be ignored, including any subsequent
valid options.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, test_create_repo() expects that templates can be found below
`pwd`/.. This assumption fails when tests are run against a git
installed somewhere else or test_create_repo() is called from
subdirectiories (several tests do this).
Therefore, use $TEST_DIRECTORY as introduced in 2d84e9fb and expect
templates to be present in $TEST_DIRECTORY/.. which should be the root
dir of the git checkout.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These scripts all test git programs that are written in
perl, and thus obviously won't work if NO_PERL is defined.
We pass NO_PERL to the scripts from the building Makefile
via the GIT-BUILD-OPTIONS file.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Bring documentation in test-lib and clean target
in Makefile in-line with abc5d372.
Signed-off-by: Emil Sit <sit@emilsit.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The implementation of exec on Windows is just a rough approximation of the
POSIX behavior. In particular, no real process "overlay" happens (a new
process is spawned instead and the parent process waits until the child
terminates). In particular, the process ID cannot be taken by the exec'd
process. But there is one test in t7502-commit.sh that depends on this.
We have to skip it on Windows.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
* js/windows-tests:
t0060: fix whitespace in "wc -c" invocation
t5503: GIT_DEBUG_SEND_PACK is not supported on MinGW
t7004: Use prerequisite tags to skip tests that need gpg
Use prerequisites to skip tests that need unzip
t3700: Skip a test with backslashes in pathspec
Skip tests that require a filesystem that obeys POSIX permissions
t0060: Fix tests on Windows
Use prerequisite tags to skip tests that depend on symbolic links
t9100, t9129: Use prerequisite tags for UTF-8 tests
t5302: Use prerequisite tags to skip 64-bit offset tests
Skip tests that fail if the executable bit is not handled by the filesystem
t3600: Use test prerequisite tags
test-lib: Infrastructure to test and check for prerequisites
t0050: Check whether git init detected symbolic link support correctly
Tests on Windows: $(pwd) must return Windows-style paths
test-lib: Work around missing sum on Windows
test-lib: Work around incompatible sort and find on Windows
Conflicts:
t/t3000-ls-files-others.sh
The test verifies that glob special characters can be escaped with
backslashes. In particular, the string fo\[ou\]bar is given to git.
On Windows, this does not work because backslashes are first of all
directory separators, and first thing git does with a pathspec from the
command line is to convert backslashes to forward slashes.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Many tests depend on that symbolic links work. This introduces a check
that sets the prerequisite tag SYMLINKS if the file system supports
symbolic links. Since so many tests have to check for this prerequisite,
we do the check in test-lib.sh, so that we don't need to repeat the test
in many scripts.
To check for 'ln -s' failures, you can use a FAT partition on Linux:
$ mkdosfs -C git-on-fat 1000000
$ sudo mount -o loop,uid=j6t,gid=users,shortname=winnt git-on-fat /mnt
Clone git to /mnt and
$ GIT_SKIP_TESTS='t0001.1[34] t0010 t1301 t403[34] t4129.[47] t5701.7
t7701.3 t9100 t9101.26 t9119 t9124.[67] t9200.10 t9600.6' \
make test
(These additionally skipped tests depend on POSIX permissions that FAT on
Linux does not provide.)
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Some tests can be run only if a particular prerequisite is available. For
example, some tests require that an UTF-8 locale is available. Here we
introduce functions that are used in this way:
1. Insert code that checks whether the prerequisite is available. If it is,
call test_set_prereq with an arbitrary tag name that subsequently can be
used to check for the prerequisite:
case $LANG in
*.utf-8)
test_set_prereq UTF8
;;
esac
2. In the calls to test_expect_success pass the tag name:
test_expect_success UTF8 '...description...' '...tests...'
3. There is an auxiliary predicate that can be used anywhere to test for
a prerequisite explicitly:
if test_have_prereq UTF8
then
...code to be skipped if prerequisite is not available...
fi
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Many tests pass $(pwd) in some form to git and later test that the output
of git contains the correct value of $(pwd). For example, the test of
'git remote show' sets up a remote that contains $(pwd) and then the
expected result must contain $(pwd).
Again, MSYS-bash's path mangling kicks in: Plain $(pwd) uses the MSYS style
absolute path /c/path/to/git. The test case would write this name into
the 'expect' file. But when git is invoked, MSYS-bash converts this name to
the Windows style path c:/path/to/git, and git would produce this form in
the result; the test would fail.
We fix this by passing -W to bash's pwd that produces the Windows-style
path.
There are a two cases that need an accompanying change:
- In t1504 the value of $(pwd) becomes part of a path list. In this case,
the lone 'c' in something like /foo:c:/path/to/git:/bar inhibits
MSYS-bashes path mangling; IOW in this case we want the /c/path/to/git
form to allow path mangling. We use $PWD instead of $(pwd), which always
has the latter form.
- In t6200, $(pwd) - the Windows style path - must be used to construct the
expected result because that is the path form that git sees. (The change
in the test itself is just for consistency: 'git fetch' always sees the
Windows-style path, with or without the change.)
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
t1002-read-tree-m-u-2way.sh uses 'sum', but it does not rely on the exact
form of the sum, only that it is a hash digest. Therefore, we can sneak
in 'md5sum' under the name 'sum'.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
If the PATH lists the Windows system directories before the MSYS
directories, Windows's own incompatible sort and find commands would be
picked up. We implement these commands as functions and call the real
tools by absolute path.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
This function replaces sequences of 'chmod +x' and 'git update-index
--chmod=+x' in the test suite, whose purpose is to help filesystems
that need core.filemode=false. Two places where only 'chmod +x' was used
we also use this new function.
The function calls 'git update-index --chmod' without checking
core.filemode (unlike some of the call sites did). We do this because the
call sites *expect* that the executable bit ends up in the index (ie. it
is not the purpose of the call sites to *test* whether git treats
'chmod +x' and 'update-index --chmod=+x' correctly). Therefore, on
filesystems with core.filemode=true the 'git update-index --chmod' is a
no-op.
The function uses --add with update-index to help one call site in
t6031-merge-recursive. It makes no difference for the other callers.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Since the test case counter was incremented very late, there were a few
users of the counter had to do their own incrementing. Now we increment it
early and simplify these users.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
In particular:
- Test case counting can be achieved by arithmetic expansion.
- The name of the test, e.g. t1234, can be computed with ${0%%} and ${0##}.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Introduce variables GIT_TEST_INSTALLED and GIT_TEST_EXEC_PATH such that
the test suite can be run against a git which is installed at
GIT_TEST_INSTALLED with subcommands at GIT_TEST_EXEC_PATH.
GIT_TEST_INSTALLED defaults to the git.git checkout, GIT_TEST_EXEC_PATH
defaults to the output of '$GIT_TEST_INSTALLED/git --exec-path'.
Run the suite e.g. as
GIT_TEST_INSTALLED=/some/path make test
but note that this requires and uses parts of a compiled git in the
git.git checkout: test helpers, templates and perl libraries are taken
from there.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It just happens so that when GIT_EXEC_PATH points to a compiled checkout
of git.git it contains "git". Since this is not true in general make
test-lib check for "git-init" which is always in GIT_EXEC_PATH.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The earlier code meant to attempt to strip everything except the test
number, but only stripped the part starting with the last dash.
However, there is no reason why we should not use the whole basename.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* js/valgrind:
valgrind: do not require valgrind 3.4.0 or newer
test-lib: avoid assuming that templates/ are in the GIT_EXEC_PATH
Tests: let --valgrind imply --verbose and --tee
Add a script to coalesce the valgrind outputs
t/Makefile: provide a 'valgrind' target
test-lib.sh: optionally output to test-results/$TEST.out, too
Valgrind support: check for more than just programming errors
valgrind: ignore ldso and more libz errors
Add valgrind support in test scripts
* maint:
tests: fix "export var=val"
Skip timestamp differences for diff --no-index
Documentation/git-push: --all, --mirror, --tags can not be combined
Some shells do not like "export var=val"; the right way to write
it is to do an assignment and then export just the variable name.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It does not make much sense to run the (expensive) valgrind tests and
not look at the output.
To prevent output from scrolling out of reach, the parameter --tee is
implied, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When tests are run in parallel and a few tests fail, it does not help
that the output of the terminal is totally confusing, as you rarely know
which test which line came from.
So introduce the option '--tee' which triggers that the output of the
tests will be written to t/test-results/$TEST.out in addition to the
terminal, where $TEST is the basename of the script.
Unfortunately, there seems to be no way to redirect a given file
descriptor to a specified subprocess in POSIX shell, only redirection
to a file is supported via 'exec > $FILE'.
At least with bash, one might think that 'exec >($COMMAND)' would work
as intended, but it does not.
The common way to work around the lack of proper tools support is to
work with named pipes, alas, one of our most beloved platforms does not
really support named pipes. Besides, we would need a pipe for every
script, as the whole point of this patch is to allow parallel execution.
Therefore, we handle the redirection in the following way: when '--tee'
was passed to the test script, the variable GIT_TEST_TEE_STARTED is set
(to avoid triggering that code path again) and the script is started
_again_, in a subshell, redirected to the command "tee".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch makes --valgrind try to override _all_ Git binaries in the
PATH, and it makes it an error to call *.sh and *.perl scripts directly.
While it is not strictly necessary to look through the whole PATH to
find git binaries to override, it is in line with running an expensive
test (which valgrind is) to make extra sure that only binaries are
tested that actually come from the git.git checkout.
In the same spirit, we can test that neither our test suite nor our
scripts try to run the *.sh or *.perl scripts directly.
It's more like a "because we can" than a "this is tightly connected
to valgrind", but in the author's opinion "because we can" is "so we
should" in this case.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch adds the ability to use valgrind's memcheck tool to
diagnose memory problems in Git while running the test scripts.
It requires valgrind 3.4.0 or newer.
It works by creating symlinks to a valgrind script, which have the same
name as our Git binaries, and then putting that directory in front of
the test script's PATH as well as set GIT_EXEC_PATH to that directory.
Git scripts are symlinked from that directory directly.
That way, Git binaries called by Git scripts are valgrinded, too.
Valgrind can be used by specifying "GIT_TEST_OPTS=--valgrind" in the
make invocation. Any invocation of git that finds any errors under
valgrind will exit with failure code 126. Any valgrind output will go
to the usual stderr channel for tests (i.e., /dev/null, unless -v has
been specified).
If you need to pass options to valgrind -- you might want to run
another tool than memcheck, for example -- you can set the environment
variable GIT_VALGRIND_OPTIONS.
A few default suppressions are included, since libz seems to trigger
quite a few false positives. We'll assume that libz works and that we
can ignore any errors which are reported there.
Note: it is safe to run the valgrind tests in parallel, as the links in
t/valgrind/bin/ are created using proper locking.
Initial patch and all the hard work by Jeff King.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Brian Gernhardt noticed that t3411 was broken recently on case insensitive
filesystems.
0088496 (test-lib.sh: introduce test_commit() and test_merge() helpers,
2009-01-27) used a tag and a file with the same name, only different in
case, and converted many existing tests that needed only a file (or a
tag).
Some tests may want to refer to a rev or a file, but on a filesystem that
loses cases, referring to either without disambiguation mark ("--") on the
command line now triggers an error (t3411 was the only one such test).
Fix it by using a filename that is different from the tagname each step
creates.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Often we just need to add a commit with a given (short) name, that will
be tagged with the same name. Now, relatively complicated graphs can be
constructed easily and in a clear fashion:
test_commit A &&
test_commit B &&
git checkout A &&
test_commit C &&
test_merge D B
will construct this graph:
A - B
\ \
C - D
For simplicity, files whose name is the lower case version of the commit
message (to avoid a warning about ambiguous names) will be committed, with
the corresponding commit messages as contents.
If you need to provide a different file/different contents, you can use
the more explicit form
test_commit $MESSAGE $FILENAME $CONTENTS
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In 'man 1p trap' there is written:
"Implementations may permit names with the SIG prefix or ignore case
in signal names as an extension."
So change the lowercase signals to uppercase, which is POSIX compliant
instead of being an extension.
There wasn't anybody claiming that it doesn't work, but there was a bug
with using a signal with the SIG prefix, which is an extension as well.
So let's play it safe and change it, since it doesn't hurt anyone.
While at it, also convert 8 indentation spaces to 1 tab character.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In dc871831(Only use GIT_CONFIG in "git config", not other programs),
GIT_CONFIG_LOCAL was rested in peace, in favor of not reading
/etc/gitconfig and $HOME/.gitconfig at all when GIT_CONFIG is set.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
rebase -i: do not fail when there is no commit to cherry-pick
test-lib: fix color reset in say_color()
fix pread()'s short read in index-pack
Conflicts:
csum-file.c
When executing a single test with colors enabled, the cursor was not set
back to the previous one, and you had to hit an extra enter to get it
back.
Work around this problem by calling 'tput sgr0' before printing the
final newline.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Sometimes you want to keep the trash directory, even if all tests
passed. For example, when extending tests, it comes it quite handy.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many test scripts assumed that they will start in a 'trash' subdirectory
that is a single level down from the t/ directory, and referred to their
test vector files by asking for files like "../t9999/expect". This will
break if we move the 'trash' subdirectory elsewhere.
To solve this, we earlier introduced "$TEST_DIRECTORY" so that they can
refer to t/ directory reliably. This finally makes all the tests use
it to refer to the outside environment.
With this patch, and a one-liner not included here (because it would
contradict with what Dscho really wants to do):
| diff --git a/t/test-lib.sh b/t/test-lib.sh
| index 70ea7e0..60e69e4 100644
| --- a/t/test-lib.sh
| +++ b/t/test-lib.sh
| @@ -485,7 +485,7 @@ fi
| . ../GIT-BUILD-OPTIONS
|
| # Test repository
| -test="trash directory"
| +test="trash directory/another level/yet another"
| rm -fr "$test" || {
| trap - exit
| echo >&5 "FATAL: Cannot prepare test area"
all the tests still pass, but we would want extra sets of eyeballs on this
type of change to really make sure.
[jc: with help from Stephan Beyer on http-push tests I do not run myself;
credits for locating silly quoting errors go to Olivier Marin.]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On multiprocessor machines, or with I/O heavy tests (that leave the
CPU waiting a lot), it makes sense to parallelize the tests.
However, care has to be taken that the different jobs use different
trash directories.
This commit does so, by creating the trash directories with a suffix
that is unique with regard to the test, as it is the test's base name.
Further, the trash directory is removed in the test itself if
everything went fine, so that the trash directories do not
pile up only to be removed at the very end.
If a test failed, the trash directory is not removed. Chances are
that the exact error message is lost in the clutter, but you can still
see what test failed from the name of the trash directory, and repeat
the test (without -j).
If all was good, you will see the aggregated results.
Suggestions to simplify this commit came from Junio and René.
There still is an issue with tests that want to run a server process and
listen to a fixed port (http and svn) --- they cannot run in parallel but
this patch does not address this issue.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test_must_fail function in test-lib.sh has been designed to
distinguish segmentation faults from controlled errors. But in the
current implementation this only works if a git command does not return a
small negative value, like -1, -2 or -3. But some git commands do.
Because any signal (like SIGSEGV) will result in an exit status
less than 193, this patch just adds a further check for the exit
status.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* dr/ceiling:
Eliminate an unnecessary chdir("..")
Add support for GIT_CEILING_DIRECTORIES
Fold test-absolute-path into test-path-utils
Implement normalize_absolute_path
Conflicts:
cache.h
setup.c
* sr/tests:
Hook up the result aggregation in the test makefile.
A simple script to parse the results from the testcases
Modify test-lib.sh to output stats to t/test-results/*
Conflicts:
t/test-lib.sh
This is for running external test scripts in other programming
languages that provide continuous output about their tests. Using
test_expect_success (like "test_expect_success 'description' 'perl
test-script.pl'") doesn't suffice here because test_expect_success
eats stdout in non-verbose mode, which is not fixable without major
file descriptor trickery.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a --long-tests option to test-lib.sh, which enables tests to
selectively run more exhaustive (longer running, potentially
brute-force) tests. Such exhaustive tests would only be useful if one
works on the specific module that is being tested -- for a general "cd
t/; make" to check whether everything is OK, such exhaustive tests
shouldn't be run by default since the longer it takes to run the
tests, the less often they are actually run.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Only ignore whitespace errors in t/tNNNN-*.sh and the t/tNNNN
subdirectories. Other files (like test libraries) should still be
checked.
Also fix a whitespace error in t/test-lib.sh.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This change is needed order to aggregate data on the test run later on.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this, some tests will fail because they compare command output
of subprocesses (such as git) with $PWD -- but subprocesses have the
physical path as their working directory, whereas $PWD contains the
symlinked path. This fixes it.
Signed-off-by: Lea Wiemann <LeWiemann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make git recognize a new environment variable that prevents it from
chdir'ing up into specified directories when looking for a GIT_DIR.
Useful for avoiding slow network directories.
For example, I use git in an environment where homedirs are automounted
and "ls /home/nonexistent" takes about 9 seconds. Setting
GIT_CEILING_DIRS="/home" allows "git help -a" (for bash completion) and
"git symbolic-ref" (for my shell prompt) to run in a reasonable time.
Signed-off-by: David Reiss <dreiss@facebook.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Exit with error if cd into the "trash directory" failed (error
already reported, so just exit).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In order to help prevent regressions in the future, rename the trash directory
for all tests to contain spaces. This patch also corrects two failures that
were caused or exposed by this change.
Signed-off-by: Bryan Donlan <bdonlan@fushizen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In particular, this function correctly handles cases where the pwd contains
spaces, quotes, and other troublesome metacharacters.
Signed-off-by: Bryan Donlan <bdonlan@fushizen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a git command is run under test_must_fail to make sure that
the argument parser catches bogus command line, it exits with 129.
We need to catch it as a valid "graceful error exit".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When your test creates an unwritable directory that test framework cannot
clean out by "rm -fr trash", later tests cannot start in a fresh state
they expect to. Detect this and error out early.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many scripts compare actual and expected output using
"diff -u". This is nicer than "cmp" because the output shows
how the two differ. However, not all versions of diff
understand -u, leading to unnecessary test failure.
This adds a test_cmp function to the test scripts and
switches all "diff -u" invocations to use it. The function
uses the contents of "$GIT_TEST_CMP" to compare its
arguments; the default is "diff -u".
On systems with a less-capable diff, you can do:
GIT_TEST_CMP=cmp make test
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
unquote_c_style: fix off-by-one.
test-lib: fix TERM to dumb for test repeatability
config.txt: refer to --upload-pack and --receive-pack instead of --exec
git-gui: Gracefully fall back to po2msg.sh if msgfmt --tcl fails
Dscho noticed that Term::ReadLine (used by send-email) colorized its
output for his TERM settings, inside t9001 tests.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we expect a git command to notice and signal errors, we
carelessly wrote in our tests:
test_expect_success 'reject bogus request' '
do something &&
do something else &&
! git command
'
but a non-zero exit could come from the "git command" segfaulting.
A new helper function "tset_must_fail" is introduced and it is
meant to be used to make sure the command gracefully fails (iow,
dying and exiting with non zero status is counted as a failure
to "gracefully fail"). The above example should be written as:
test_expect_success 'reject bogus request' '
do something &&
do something else &&
test_must_fail git command
'
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The top-level Makefile now creates a GIT-BUILD-OPTIONS file
which stores any options selected by the make process that
may be of use to further parts of the build process.
Specifically, we store the SHELL_PATH so that it can be used
by tests to construct shell scripts on the fly.
The format of the GIT-BUILD-OPTIONS file is Bourne shell,
and it is sourced by test-lib.sh; all tests can rely on just
having $SHELL_PATH correctly set in the environment.
The GIT-BUILD-OPTIONS file is written every time the
toplevel 'make' is invoked. Since the only users right now
are the test scripts, there's no drawback to updating its
timestamp. If something build-related depends on this, we
can do a trick similar to the one used by GIT-CFLAGS.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we expect a git command to notice and signal errors, we
carelessly wrote in our tests:
test_expect_success 'reject bogus request' '
do something &&
do something else &&
! git command
'
but a non-zero exit could come from the "git command" segfaulting.
A new helper function "tset_must_fail" is introduced and it is
meant to be used to make sure the command gracefully fails (iow,
dying and exiting with non zero status is counted as a failure
to "gracefully fail"). The above example should be written as:
test_expect_success 'reject bogus request' '
do something &&
do something else &&
test_must_fail git command
'
Signed-off-by: Junio C Hamano <gitster@pobox.com>
http-push tests require a web server with WebDAV support.
This commit introduces a HTTPD test library, which can be configured using
the following environment variables.
GIT_TEST_HTTPD enable HTTPD tests
LIB_HTTPD_PATH web server path
LIB_HTTPD_MODULE_PATH web server modules path
LIB_HTTPD_PORT listening port
LIB_HTTPD_DAV enable DAV
LIB_HTTPD_SVN enable SVN
LIB_HTTPD_SSL enable SSL
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, we set the GIT_CONFIG environment variable in
our tests so that only that file was read. However, setting
it to a static value is not correct, since we are not
necessarily always in the same directory; instead, we want
the usual git config file lookup to happen.
To do this, we stop setting GIT_CONFIG, which means that we
must now suppress the reading of the system-wide and user
configs.
This exposes an incorrect test in t1500, which is also
fixed (the incorrect test worked because we were failing to
read the core.bare value from the config file, since the
GIT_CONFIG variable was pointing us to the wrong file).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we have known breakages, we still said "passed all N
test(s)", which was a bit funny.
This rewords it to read "passed all remaining N test(s)" in such
a case.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Originally, test_expect_failure was designed to be the opposite
of test_expect_success, but this was a bad decision. Most tests
run a series of commands that leads to the single command that
needs to be tested, like this:
test_expect_{success,failure} 'test title' '
setup1 &&
setup2 &&
setup3 &&
what is to be tested
'
And expecting a failure exit from the whole sequence misses the
point of writing tests. Your setup$N that are supposed to
succeed may have failed without even reaching what you are
trying to test. The only valid use of test_expect_failure is to
check a trivial single command that is expected to fail, which
is a minority in tests of Porcelain-ish commands.
This large-ish patch rewrites all uses of test_expect_failure to
use test_expect_success and rewrites the condition of what is
tested, like this:
test_expect_success 'test title' '
setup1 &&
setup2 &&
setup3 &&
! this command should fail
'
test_expect_failure is redefined to serve as a reminder that
that test *should* succeed but due to a known breakage in git it
currently does not pass. So if git-foo command should create a
file 'bar' but you discovered a bug that it doesn't, you can
write a test like this:
test_expect_failure 'git-foo should create bar' '
rm -f bar &&
git foo &&
test -f bar
'
This construct acts similar to test_expect_success, but instead
of reporting "ok/FAIL" like test_expect_success does, the
outcome is reported as "FIXED/still broken".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch removes a spurious "command not found" error
and actually makes the "Test script did not set test_description."
string follow the command line option "--no-color".
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This shuts down the "* ok ##: `test description`" messages.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ei/worktree+filter:
filter-branch: always export GIT_DIR if it is set
setup_git_directory: fix segfault if repository is found in cwd
test GIT_WORK_TREE
extend rev-parse test for --is-inside-work-tree
Use new semantics of is_bare/inside_git_dir/inside_work_tree
introduce GIT_WORK_TREE to specify the work tree
test git rev-parse
rev-parse: introduce --is-bare-repository
rev-parse: document --is-inside-git-dir
This uses "git-apply --whitespace=strip" to fix whitespace errors that have
crept in to our source files over time. There are a few files that need
to have trailing whitespaces (most notably, test vectors). The results
still passes the test, and build result in Documentation/ area is unchanged.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
setup_gdg is used as abbreviation for setup_git_directory_gently.
The work tree can be specified using the environment variable
GIT_WORK_TREE and the config option core.worktree (the environment
variable has precendence over the config option). Additionally
there is a command line option --work-tree which sets the
environment variable.
setup_gdg does the following now:
GIT_DIR unspecified
repository in .git directory
parent directory of the .git directory is used as work tree,
GIT_WORK_TREE is ignored
GIT_DIR unspecified
repository in cwd
GIT_DIR is set to cwd
see the cases with GIT_DIR specified what happens next and
also see the note below
GIT_DIR specified
GIT_WORK_TREE/core.worktree unspecified
cwd is used as work tree
GIT_DIR specified
GIT_WORK_TREE/core.worktree specified
the specified work tree is used
Note on the case where GIT_DIR is unspecified and repository is in cwd:
GIT_WORK_TREE is used but is_inside_git_dir is always true.
I did it this way because setup_gdg might be called multiple
times (e.g. when doing alias expansion) and in successive calls
setup_gdg should do the same thing every time.
Meaning of is_bare/is_inside_work_tree/is_inside_git_dir:
(1) is_bare_repository
A repository is bare if core.bare is true or core.bare is
unspecified and the name suggests it is bare (directory not
named .git). The bare option disables a few protective
checks which are useful with a working tree. Currently
this changes if a repository is bare:
updates of HEAD are allowed
git gc packs the refs
the reflog is disabled by default
(2) is_inside_work_tree
True if the cwd is inside the associated working tree (if there
is one), false otherwise.
(3) is_inside_git_dir
True if the cwd is inside the git directory, false otherwise.
Before this patch is_inside_git_dir was always true for bare
repositories.
When setup_gdg finds a repository git_config(git_default_config) is
always called. This ensure that is_bare_repository makes use of
core.bare and does not guess even though core.bare is specified.
inside_work_tree and inside_git_dir are set if setup_gdg finds a
repository. The is_inside_work_tree and is_inside_git_dir functions
will die if they are called before a successful call to setup_gdg.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some other programs get the user's email address from $EMAIL, so fall back to
that if we don't have a Git-specific email address.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
