2013-11-25 21:03:06 +00:00
|
|
|
# Library of functions shared by all tests scripts, included by
|
|
|
|
# test-lib.sh.
|
2012-02-17 10:25:08 +00:00
|
|
|
#
|
|
|
|
# Copyright (c) 2005 Junio C Hamano
|
|
|
|
#
|
|
|
|
# This program is free software: you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU General Public License as published by
|
|
|
|
# the Free Software Foundation, either version 2 of the License, or
|
|
|
|
# (at your option) any later version.
|
|
|
|
#
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU General Public License
|
2023-11-24 03:35:13 +00:00
|
|
|
# along with this program. If not, see https://www.gnu.org/licenses/ .
|
2012-02-17 10:25:08 +00:00
|
|
|
|
|
|
|
# The semantics of the editor variables are that of invoking
|
|
|
|
# sh -c "$EDITOR \"$@\"" files ...
|
|
|
|
#
|
|
|
|
# If our trash directory contains shell metacharacters, they will be
|
|
|
|
# interpreted if we just set $EDITOR directly, so do a little dance with
|
|
|
|
# environment variables to work around this.
|
|
|
|
#
|
|
|
|
# In particular, quoting isn't enough, as the path may contain the same quote
|
|
|
|
# that we're using.
|
|
|
|
test_set_editor () {
|
|
|
|
FAKE_EDITOR="$1"
|
|
|
|
export FAKE_EDITOR
|
|
|
|
EDITOR='"$FAKE_EDITOR"'
|
|
|
|
export EDITOR
|
|
|
|
}
|
|
|
|
|
2023-02-23 20:55:01 +00:00
|
|
|
# Like test_set_editor but sets GIT_SEQUENCE_EDITOR instead of EDITOR
|
|
|
|
test_set_sequence_editor () {
|
|
|
|
FAKE_SEQUENCE_EDITOR="$1"
|
|
|
|
export FAKE_SEQUENCE_EDITOR
|
|
|
|
GIT_SEQUENCE_EDITOR='"$FAKE_SEQUENCE_EDITOR"'
|
|
|
|
export GIT_SEQUENCE_EDITOR
|
|
|
|
}
|
|
|
|
|
2012-02-17 10:25:08 +00:00
|
|
|
test_decode_color () {
|
|
|
|
awk '
|
|
|
|
function name(n) {
|
|
|
|
if (n == 0) return "RESET";
|
|
|
|
if (n == 1) return "BOLD";
|
2018-08-14 01:41:15 +00:00
|
|
|
if (n == 2) return "FAINT";
|
|
|
|
if (n == 3) return "ITALIC";
|
2017-07-13 14:58:41 +00:00
|
|
|
if (n == 7) return "REVERSE";
|
2012-02-17 10:25:08 +00:00
|
|
|
if (n == 30) return "BLACK";
|
|
|
|
if (n == 31) return "RED";
|
|
|
|
if (n == 32) return "GREEN";
|
|
|
|
if (n == 33) return "YELLOW";
|
|
|
|
if (n == 34) return "BLUE";
|
|
|
|
if (n == 35) return "MAGENTA";
|
|
|
|
if (n == 36) return "CYAN";
|
|
|
|
if (n == 37) return "WHITE";
|
|
|
|
if (n == 40) return "BLACK";
|
|
|
|
if (n == 41) return "BRED";
|
|
|
|
if (n == 42) return "BGREEN";
|
|
|
|
if (n == 43) return "BYELLOW";
|
|
|
|
if (n == 44) return "BBLUE";
|
|
|
|
if (n == 45) return "BMAGENTA";
|
|
|
|
if (n == 46) return "BCYAN";
|
|
|
|
if (n == 47) return "BWHITE";
|
|
|
|
}
|
|
|
|
{
|
|
|
|
while (match($0, /\033\[[0-9;]*m/) != 0) {
|
|
|
|
printf "%s<", substr($0, 1, RSTART-1);
|
|
|
|
codes = substr($0, RSTART+2, RLENGTH-3);
|
|
|
|
if (length(codes) == 0)
|
|
|
|
printf "%s", name(0)
|
|
|
|
else {
|
|
|
|
n = split(codes, ary, ";");
|
|
|
|
sep = "";
|
|
|
|
for (i = 1; i <= n; i++) {
|
|
|
|
printf "%s%s", sep, name(ary[i]);
|
|
|
|
sep = ";"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
printf ">";
|
|
|
|
$0 = substr($0, RSTART + RLENGTH, length($0) - RSTART - RLENGTH + 1);
|
|
|
|
}
|
|
|
|
print
|
|
|
|
}
|
|
|
|
'
|
|
|
|
}
|
|
|
|
|
2016-08-11 14:46:01 +00:00
|
|
|
lf_to_nul () {
|
|
|
|
perl -pe 'y/\012/\000/'
|
|
|
|
}
|
|
|
|
|
2012-02-17 10:25:08 +00:00
|
|
|
nul_to_q () {
|
2013-10-29 01:23:03 +00:00
|
|
|
perl -pe 'y/\000/Q/'
|
2012-02-17 10:25:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
q_to_nul () {
|
2013-10-29 01:23:03 +00:00
|
|
|
perl -pe 'y/Q/\000/'
|
2012-02-17 10:25:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
q_to_cr () {
|
|
|
|
tr Q '\015'
|
|
|
|
}
|
|
|
|
|
|
|
|
q_to_tab () {
|
|
|
|
tr Q '\011'
|
|
|
|
}
|
|
|
|
|
2013-03-22 18:10:03 +00:00
|
|
|
qz_to_tab_space () {
|
|
|
|
tr QZ '\011\040'
|
2012-02-17 10:25:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
append_cr () {
|
|
|
|
sed -e 's/$/Q/' | tr Q '\015'
|
|
|
|
}
|
|
|
|
|
|
|
|
remove_cr () {
|
|
|
|
tr '\015' Q | sed -e 's/Q$//'
|
|
|
|
}
|
|
|
|
|
|
|
|
# In some bourne shell implementations, the "unset" builtin returns
|
|
|
|
# nonzero status when a variable to be unset was not set in the first
|
|
|
|
# place.
|
|
|
|
#
|
|
|
|
# Use sane_unset when that should not be considered an error.
|
|
|
|
|
|
|
|
sane_unset () {
|
|
|
|
unset "$@"
|
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
|
|
|
test_tick () {
|
|
|
|
if test -z "${test_tick+set}"
|
|
|
|
then
|
|
|
|
test_tick=1112911993
|
|
|
|
else
|
|
|
|
test_tick=$(($test_tick + 60))
|
|
|
|
fi
|
|
|
|
GIT_COMMITTER_DATE="$test_tick -0700"
|
|
|
|
GIT_AUTHOR_DATE="$test_tick -0700"
|
|
|
|
export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
|
|
|
|
}
|
|
|
|
|
2017-03-18 16:14:00 +00:00
|
|
|
# Stop execution and start a shell. This is useful for debugging tests.
|
2012-02-17 10:25:08 +00:00
|
|
|
#
|
|
|
|
# Be sure to remove all invocations of this command before submitting.
|
test-lib-functions: optionally keep HOME, TERM and SHELL in 'test_pause'
The 'test_pause' function, which is designed to help interactive
debugging and exploration of tests, currently inherits the value of HOME
and TERM set by 'test-lib.sh': HOME="$TRASH_DIRECTORY" and TERM=dumb. It
also invokes the shell defined by TEST_SHELL_PATH, which defaults to
/bin/sh (through SHELL_PATH).
Changing the value of HOME means that any customization configured in a
developers' shell startup files and any Git aliases defined in their
global Git configuration file are not available in the shell invoked by
'test_pause'.
Changing the value of TERM to 'dumb' means that colored output
is disabled for all commands in that shell.
Using /bin/sh as the shell invoked by 'test_pause' is not ideal since
some platforms (i.e. Debian and derivatives) use Dash as /bin/sh, and
this shell is usually compiled without readline support, which makes for
a poor interactive command line experience.
To make the interactive command line experience in the shell invoked by
'test_pause' more pleasant, save the values of HOME and TERM in
USER_HOME and USER_TERM before changing them in test-lib.sh, and add
options to 'test_pause' to optionally use these variables to invoke the
shell. Also add an option to invoke SHELL instead of TEST_SHELL_PATH, so
that developer's interactive shell is used.
We use options instead of changing the behaviour unconditionally since
these three variables can slightly change command behaviour. Moreover,
using the original HOME means commands could overwrite files in a user's
home directory. Be explicit about these caveats in the new 'Usage'
section in test-lib-functions.sh.
Finally, add '[options]' to the test_pause synopsys in t/README, and
mention that the full list of helper functions and their options can be
found in test-lib-functions.sh.
Helped-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
Acked-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-06 04:38:59 +00:00
|
|
|
# WARNING: the shell invoked by this helper does not have the same environment
|
|
|
|
# as the one running the tests (shell variables and functions are not
|
|
|
|
# available, and the options below further modify the environment). As such,
|
|
|
|
# commands copied from a test script might behave differently than when
|
|
|
|
# running the test.
|
|
|
|
#
|
|
|
|
# Usage: test_pause [options]
|
|
|
|
# -t
|
|
|
|
# Use your original TERM instead of test-lib.sh's "dumb".
|
|
|
|
# This usually restores color output in the invoked shell.
|
|
|
|
# -s
|
|
|
|
# Invoke $SHELL instead of $TEST_SHELL_PATH.
|
|
|
|
# -h
|
|
|
|
# Use your original HOME instead of test-lib.sh's "$TRASH_DIRECTORY".
|
|
|
|
# This allows you to use your regular shell environment and Git aliases.
|
|
|
|
# CAUTION: running commands copied from a test script into the paused shell
|
|
|
|
# might result in files in your HOME being overwritten.
|
|
|
|
# -a
|
|
|
|
# Shortcut for -t -s -h
|
2012-02-17 10:25:08 +00:00
|
|
|
|
|
|
|
test_pause () {
|
test-lib-functions: optionally keep HOME, TERM and SHELL in 'test_pause'
The 'test_pause' function, which is designed to help interactive
debugging and exploration of tests, currently inherits the value of HOME
and TERM set by 'test-lib.sh': HOME="$TRASH_DIRECTORY" and TERM=dumb. It
also invokes the shell defined by TEST_SHELL_PATH, which defaults to
/bin/sh (through SHELL_PATH).
Changing the value of HOME means that any customization configured in a
developers' shell startup files and any Git aliases defined in their
global Git configuration file are not available in the shell invoked by
'test_pause'.
Changing the value of TERM to 'dumb' means that colored output
is disabled for all commands in that shell.
Using /bin/sh as the shell invoked by 'test_pause' is not ideal since
some platforms (i.e. Debian and derivatives) use Dash as /bin/sh, and
this shell is usually compiled without readline support, which makes for
a poor interactive command line experience.
To make the interactive command line experience in the shell invoked by
'test_pause' more pleasant, save the values of HOME and TERM in
USER_HOME and USER_TERM before changing them in test-lib.sh, and add
options to 'test_pause' to optionally use these variables to invoke the
shell. Also add an option to invoke SHELL instead of TEST_SHELL_PATH, so
that developer's interactive shell is used.
We use options instead of changing the behaviour unconditionally since
these three variables can slightly change command behaviour. Moreover,
using the original HOME means commands could overwrite files in a user's
home directory. Be explicit about these caveats in the new 'Usage'
section in test-lib-functions.sh.
Finally, add '[options]' to the test_pause synopsys in t/README, and
mention that the full list of helper functions and their options can be
found in test-lib-functions.sh.
Helped-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
Acked-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-06 04:38:59 +00:00
|
|
|
PAUSE_TERM=$TERM &&
|
|
|
|
PAUSE_SHELL=$TEST_SHELL_PATH &&
|
|
|
|
PAUSE_HOME=$HOME &&
|
|
|
|
while test $# != 0
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
-t)
|
|
|
|
PAUSE_TERM="$USER_TERM"
|
|
|
|
;;
|
|
|
|
-s)
|
|
|
|
PAUSE_SHELL="$SHELL"
|
|
|
|
;;
|
|
|
|
-h)
|
|
|
|
PAUSE_HOME="$USER_HOME"
|
|
|
|
;;
|
|
|
|
-a)
|
|
|
|
PAUSE_TERM="$USER_TERM"
|
|
|
|
PAUSE_SHELL="$SHELL"
|
|
|
|
PAUSE_HOME="$USER_HOME"
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
shift
|
|
|
|
done &&
|
|
|
|
TERM="$PAUSE_TERM" HOME="$PAUSE_HOME" "$PAUSE_SHELL" <&6 >&5 2>&7
|
2012-02-17 10:25:08 +00:00
|
|
|
}
|
|
|
|
|
2018-04-24 23:46:45 +00:00
|
|
|
# Wrap git with a debugger. Adding this to a command can make it easier
|
|
|
|
# to understand what is going on in a failing test.
|
2015-10-30 19:02:56 +00:00
|
|
|
#
|
2021-09-06 04:39:00 +00:00
|
|
|
# Usage: debug [options] <git command>
|
|
|
|
# -d <debugger>
|
|
|
|
# --debugger=<debugger>
|
|
|
|
# Use <debugger> instead of GDB
|
|
|
|
# -t
|
|
|
|
# Use your original TERM instead of test-lib.sh's "dumb".
|
|
|
|
# This usually restores color output in the debugger.
|
|
|
|
# WARNING: the command being debugged might behave differently than when
|
|
|
|
# running the test.
|
|
|
|
#
|
2018-04-24 23:46:45 +00:00
|
|
|
# Examples:
|
|
|
|
# debug git checkout master
|
|
|
|
# debug --debugger=nemiver git $ARGS
|
|
|
|
# debug -d "valgrind --tool=memcheck --track-origins=yes" git $ARGS
|
2015-10-30 19:02:56 +00:00
|
|
|
debug () {
|
2021-09-06 04:39:00 +00:00
|
|
|
GIT_DEBUGGER=1 &&
|
|
|
|
DEBUG_TERM=$TERM &&
|
|
|
|
while test $# != 0
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
-t)
|
|
|
|
DEBUG_TERM="$USER_TERM"
|
|
|
|
;;
|
|
|
|
-d)
|
|
|
|
GIT_DEBUGGER="$2" &&
|
|
|
|
shift
|
|
|
|
;;
|
|
|
|
--debugger=*)
|
|
|
|
GIT_DEBUGGER="${1#*=}"
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
shift
|
|
|
|
done &&
|
|
|
|
|
|
|
|
dotfiles=".gdbinit .lldbinit"
|
|
|
|
|
|
|
|
for dotfile in $dotfiles
|
|
|
|
do
|
|
|
|
dotfile="$USER_HOME/$dotfile" &&
|
|
|
|
test -f "$dotfile" && cp "$dotfile" "$HOME" || :
|
|
|
|
done &&
|
|
|
|
|
|
|
|
TERM="$DEBUG_TERM" GIT_DEBUGGER="${GIT_DEBUGGER}" "$@" <&6 >&5 2>&7 &&
|
|
|
|
|
|
|
|
for dotfile in $dotfiles
|
|
|
|
do
|
|
|
|
rm -f "$HOME/$dotfile"
|
|
|
|
done
|
2015-10-30 19:02:56 +00:00
|
|
|
}
|
|
|
|
|
2023-10-31 08:16:59 +00:00
|
|
|
# Usage: test_ref_exists [options] <ref>
|
|
|
|
#
|
|
|
|
# -C <dir>:
|
|
|
|
# Run all git commands in directory <dir>
|
|
|
|
#
|
|
|
|
# This helper function checks whether a reference exists. Symrefs or object IDs
|
|
|
|
# will not be resolved. Can be used to check references with bad names.
|
|
|
|
test_ref_exists () {
|
|
|
|
local indir=
|
|
|
|
|
|
|
|
while test $# != 0
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
-C)
|
|
|
|
indir="$2"
|
|
|
|
shift
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
shift
|
|
|
|
done &&
|
|
|
|
|
|
|
|
indir=${indir:+"$indir"/} &&
|
|
|
|
|
|
|
|
if test "$#" != 1
|
|
|
|
then
|
|
|
|
BUG "expected exactly one reference"
|
|
|
|
fi &&
|
|
|
|
|
|
|
|
git ${indir:+ -C "$indir"} show-ref --exists "$1"
|
|
|
|
}
|
|
|
|
|
|
|
|
# Behaves the same as test_ref_exists, except that it checks for the absence of
|
|
|
|
# a reference. This is preferable to `! test_ref_exists` as this function is
|
|
|
|
# able to distinguish actually-missing references from other, generic errors.
|
|
|
|
test_ref_missing () {
|
|
|
|
test_ref_exists "$@"
|
|
|
|
case "$?" in
|
|
|
|
2)
|
|
|
|
# This is the good case.
|
|
|
|
return 0
|
|
|
|
;;
|
|
|
|
0)
|
|
|
|
echo >&4 "test_ref_missing: reference exists"
|
|
|
|
return 1
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
echo >&4 "test_ref_missing: generic error"
|
|
|
|
return 1
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
2021-01-12 20:17:56 +00:00
|
|
|
# Usage: test_commit [options] <message> [<file> [<contents> [<tag>]]]
|
|
|
|
# -C <dir>:
|
|
|
|
# Run all git commands in directory <dir>
|
2021-01-12 20:17:57 +00:00
|
|
|
# --notick
|
|
|
|
# Do not call test_tick before making a commit
|
2021-01-12 20:17:59 +00:00
|
|
|
# --append
|
2021-05-10 14:19:02 +00:00
|
|
|
# Use ">>" instead of ">" when writing "<contents>" to "<file>"
|
2021-05-10 14:19:06 +00:00
|
|
|
# --printf
|
|
|
|
# Use "printf" instead of "echo" when writing "<contents>" to
|
|
|
|
# "<file>", use this to write escape sequences such as "\0", a
|
|
|
|
# trailing "\n" won't be added automatically. This option
|
|
|
|
# supports nothing but the FORMAT of printf(1), i.e. no custom
|
|
|
|
# ARGUMENT(s).
|
2021-01-12 20:17:57 +00:00
|
|
|
# --signoff
|
|
|
|
# Invoke "git commit" with --signoff
|
2021-01-14 23:02:40 +00:00
|
|
|
# --author <author>
|
|
|
|
# Invoke "git commit" with --author <author>
|
2021-05-10 14:19:03 +00:00
|
|
|
# --no-tag
|
|
|
|
# Do not tag the resulting commit
|
2021-05-10 14:19:04 +00:00
|
|
|
# --annotate
|
|
|
|
# Create an annotated tag with "--annotate -m <message>". Calls
|
|
|
|
# test_tick between making the commit and tag, unless --notick
|
|
|
|
# is given.
|
2012-02-17 10:25:08 +00:00
|
|
|
#
|
|
|
|
# This will commit a file with the given contents and the given commit
|
2013-02-12 10:17:30 +00:00
|
|
|
# message, and tag the resulting commit with the given tag name.
|
2012-02-17 10:25:08 +00:00
|
|
|
#
|
2013-02-12 10:17:30 +00:00
|
|
|
# <file>, <contents>, and <tag> all default to <message>.
|
2012-02-17 10:25:08 +00:00
|
|
|
|
|
|
|
test_commit () {
|
2022-10-21 15:13:31 +00:00
|
|
|
local notick= &&
|
|
|
|
local echo=echo &&
|
|
|
|
local append= &&
|
|
|
|
local author= &&
|
|
|
|
local signoff= &&
|
|
|
|
local indir= &&
|
|
|
|
local tag=light &&
|
2012-09-14 06:52:03 +00:00
|
|
|
while test $# != 0
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
--notick)
|
|
|
|
notick=yes
|
|
|
|
;;
|
2021-05-10 14:19:06 +00:00
|
|
|
--printf)
|
|
|
|
echo=printf
|
|
|
|
;;
|
2021-01-12 20:17:59 +00:00
|
|
|
--append)
|
|
|
|
append=yes
|
|
|
|
;;
|
2021-01-12 20:17:58 +00:00
|
|
|
--author)
|
|
|
|
author="$2"
|
|
|
|
shift
|
|
|
|
;;
|
2012-09-14 06:52:03 +00:00
|
|
|
--signoff)
|
|
|
|
signoff="$1"
|
|
|
|
;;
|
commit-graph: implement generation data chunk
As discovered by Ævar, we cannot increment graph version to
distinguish between generation numbers v1 and v2 [1]. Thus, one of
pre-requistes before implementing generation number v2 was to
distinguish between graph versions in a backwards compatible manner.
We are going to introduce a new chunk called Generation DATa chunk (or
GDAT). GDAT will store corrected committer date offsets whereas CDAT
will still store topological level.
Old Git does not understand GDAT chunk and would ignore it, reading
topological levels from CDAT. New Git can parse GDAT and take advantage
of newer generation numbers, falling back to topological levels when
GDAT chunk is missing (as it would happen with a commit-graph written
by old Git).
We introduce a test environment variable 'GIT_TEST_COMMIT_GRAPH_NO_GDAT'
which forces commit-graph file to be written without generation data
chunk to emulate a commit-graph file written by old Git.
To minimize the space required to store corrrected commit date, Git
stores corrected commit date offsets into the commit-graph file, instea
of corrected commit dates. This saves us 4 bytes per commit, decreasing
the GDAT chunk size by half, but it's possible for the offset to
overflow the 4-bytes allocated for storage. As such overflows are and
should be exceedingly rare, we use the following overflow management
scheme:
We introduce a new commit-graph chunk, Generation Data OVerflow ('GDOV')
to store corrected commit dates for commits with offsets greater than
GENERATION_NUMBER_V2_OFFSET_MAX.
If the offset is greater than GENERATION_NUMBER_V2_OFFSET_MAX, we set
the MSB of the offset and the other bits store the position of corrected
commit date in GDOV chunk, similar to how Extra Edge List is maintained.
We test the overflow-related code with the following repo history:
F - N - U
/ \
U - N - U N
\ /
N - F - N
Where the commits denoted by U have committer date of zero seconds
since Unix epoch, the commits denoted by N have committer date of
1112354055 (default committer date for the test suite) seconds since
Unix epoch and the commits denoted by F have committer date of
(2 ^ 31 - 2) seconds since Unix epoch.
The largest offset observed is 2 ^ 31, just large enough to overflow.
[1]: https://lore.kernel.org/git/87a7gdspo4.fsf@evledraar.gmail.com/
Signed-off-by: Abhishek Kumar <abhishekkumar8222@gmail.com>
Reviewed-by: Taylor Blau <me@ttaylorr.com>
Reviewed-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-16 18:11:15 +00:00
|
|
|
--date)
|
|
|
|
notick=yes
|
|
|
|
GIT_COMMITTER_DATE="$2"
|
|
|
|
GIT_AUTHOR_DATE="$2"
|
|
|
|
shift
|
|
|
|
;;
|
2016-12-08 21:03:26 +00:00
|
|
|
-C)
|
|
|
|
indir="$2"
|
|
|
|
shift
|
|
|
|
;;
|
2021-02-09 10:52:45 +00:00
|
|
|
--no-tag)
|
2021-05-10 14:19:04 +00:00
|
|
|
tag=none
|
|
|
|
;;
|
|
|
|
--annotate)
|
|
|
|
tag=annotate
|
2021-02-09 10:52:45 +00:00
|
|
|
;;
|
2012-09-14 06:52:03 +00:00
|
|
|
*)
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
esac
|
2012-07-22 19:54:08 +00:00
|
|
|
shift
|
2012-09-14 06:52:03 +00:00
|
|
|
done &&
|
2016-12-08 21:03:26 +00:00
|
|
|
indir=${indir:+"$indir"/} &&
|
2022-10-21 15:13:31 +00:00
|
|
|
local file=${2:-"$1.t"} &&
|
2021-01-12 20:17:59 +00:00
|
|
|
if test -n "$append"
|
|
|
|
then
|
2021-05-10 14:19:06 +00:00
|
|
|
$echo "${3-$1}" >>"$indir$file"
|
2021-01-12 20:17:59 +00:00
|
|
|
else
|
2021-05-10 14:19:06 +00:00
|
|
|
$echo "${3-$1}" >"$indir$file"
|
2021-01-12 20:17:59 +00:00
|
|
|
fi &&
|
2022-03-17 18:08:39 +00:00
|
|
|
git ${indir:+ -C "$indir"} add -- "$file" &&
|
2012-07-22 19:54:08 +00:00
|
|
|
if test -z "$notick"
|
|
|
|
then
|
|
|
|
test_tick
|
|
|
|
fi &&
|
2021-01-12 20:17:58 +00:00
|
|
|
git ${indir:+ -C "$indir"} commit \
|
|
|
|
${author:+ --author "$author"} \
|
|
|
|
$signoff -m "$1" &&
|
2021-05-10 14:19:04 +00:00
|
|
|
case "$tag" in
|
|
|
|
none)
|
|
|
|
;;
|
|
|
|
light)
|
2021-02-09 10:52:45 +00:00
|
|
|
git ${indir:+ -C "$indir"} tag "${4:-$1}"
|
2021-05-10 14:19:04 +00:00
|
|
|
;;
|
|
|
|
annotate)
|
|
|
|
if test -z "$notick"
|
|
|
|
then
|
|
|
|
test_tick
|
|
|
|
fi &&
|
|
|
|
git ${indir:+ -C "$indir"} tag -a -m "$1" "${4:-$1}"
|
|
|
|
;;
|
|
|
|
esac
|
2012-02-17 10:25:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
# Call test_merge with the arguments "<message> <commit>", where <commit>
|
|
|
|
# can be a tag pointing to the commit-to-merge.
|
|
|
|
|
|
|
|
test_merge () {
|
2019-10-04 00:23:13 +00:00
|
|
|
label="$1" &&
|
|
|
|
shift &&
|
2012-02-17 10:25:08 +00:00
|
|
|
test_tick &&
|
2019-10-04 00:23:13 +00:00
|
|
|
git merge -m "$label" "$@" &&
|
|
|
|
git tag "$label"
|
2012-02-17 10:25:08 +00:00
|
|
|
}
|
|
|
|
|
test-lib: introduce test_commit_bulk
Some tests need to create a string of commits. Doing this with
test_commit is very heavy-weight, as it needs at least one process per
commit (and in fact, uses several).
For bulk creation, we can do much better by using fast-import, but it's
often a pain to generate the input. Let's provide a helper to do so.
We'll use t5310 as a guinea pig, as it has three 10-commit loops. Here
are hyperfine results before and after:
[before]
Benchmark #1: ./t5310-pack-bitmaps.sh --root=/var/ram/git-tests
Time (mean ± σ): 2.846 s ± 0.305 s [User: 3.042 s, System: 0.919 s]
Range (min … max): 2.250 s … 3.210 s 10 runs
[after]
Benchmark #1: ./t5310-pack-bitmaps.sh --root=/var/ram/git-tests
Time (mean ± σ): 2.210 s ± 0.174 s [User: 2.570 s, System: 0.604 s]
Range (min … max): 1.999 s … 2.590 s 10 runs
So we're over 20% faster, while making the callers slightly shorter. We
added a lot more lines in test-lib-function.sh, of course, and the
helper is way more featureful than we need here. But my hope is that it
will be flexible enough to use in more places.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-02 05:16:49 +00:00
|
|
|
# Efficiently create <nr> commits, each with a unique number (from 1 to <nr>
|
|
|
|
# by default) in the commit message.
|
|
|
|
#
|
|
|
|
# Usage: test_commit_bulk [options] <nr>
|
|
|
|
# -C <dir>:
|
|
|
|
# Run all git commands in directory <dir>
|
|
|
|
# --ref=<n>:
|
|
|
|
# ref on which to create commits (default: HEAD)
|
|
|
|
# --start=<n>:
|
|
|
|
# number commit messages from <n> (default: 1)
|
|
|
|
# --message=<msg>:
|
|
|
|
# use <msg> as the commit mesasge (default: "commit %s")
|
|
|
|
# --filename=<fn>:
|
|
|
|
# modify <fn> in each commit (default: %s.t)
|
|
|
|
# --contents=<string>:
|
|
|
|
# place <string> in each file (default: "content %s")
|
|
|
|
# --id=<string>:
|
|
|
|
# shorthand to use <string> and %s in message, filename, and contents
|
|
|
|
#
|
|
|
|
# The message, filename, and contents strings are evaluated by printf, with the
|
|
|
|
# first "%s" replaced by the current commit number. So you can do:
|
|
|
|
#
|
|
|
|
# test_commit_bulk --filename=file --contents="modification %s"
|
|
|
|
#
|
|
|
|
# to have every commit touch the same file, but with unique content.
|
|
|
|
#
|
|
|
|
test_commit_bulk () {
|
|
|
|
tmpfile=.bulk-commit.input
|
|
|
|
indir=.
|
|
|
|
ref=HEAD
|
|
|
|
n=1
|
|
|
|
message='commit %s'
|
|
|
|
filename='%s.t'
|
|
|
|
contents='content %s'
|
|
|
|
while test $# -gt 0
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
-C)
|
|
|
|
indir=$2
|
|
|
|
shift
|
|
|
|
;;
|
|
|
|
--ref=*)
|
|
|
|
ref=${1#--*=}
|
|
|
|
;;
|
|
|
|
--start=*)
|
|
|
|
n=${1#--*=}
|
|
|
|
;;
|
|
|
|
--message=*)
|
|
|
|
message=${1#--*=}
|
|
|
|
;;
|
|
|
|
--filename=*)
|
|
|
|
filename=${1#--*=}
|
|
|
|
;;
|
|
|
|
--contents=*)
|
|
|
|
contents=${1#--*=}
|
|
|
|
;;
|
|
|
|
--id=*)
|
|
|
|
message="${1#--*=} %s"
|
|
|
|
filename="${1#--*=}-%s.t"
|
|
|
|
contents="${1#--*=} %s"
|
|
|
|
;;
|
|
|
|
-*)
|
|
|
|
BUG "invalid test_commit_bulk option: $1"
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
shift
|
|
|
|
done
|
|
|
|
total=$1
|
|
|
|
|
|
|
|
add_from=
|
2019-11-25 12:59:07 +00:00
|
|
|
if git -C "$indir" rev-parse --quiet --verify "$ref"
|
test-lib: introduce test_commit_bulk
Some tests need to create a string of commits. Doing this with
test_commit is very heavy-weight, as it needs at least one process per
commit (and in fact, uses several).
For bulk creation, we can do much better by using fast-import, but it's
often a pain to generate the input. Let's provide a helper to do so.
We'll use t5310 as a guinea pig, as it has three 10-commit loops. Here
are hyperfine results before and after:
[before]
Benchmark #1: ./t5310-pack-bitmaps.sh --root=/var/ram/git-tests
Time (mean ± σ): 2.846 s ± 0.305 s [User: 3.042 s, System: 0.919 s]
Range (min … max): 2.250 s … 3.210 s 10 runs
[after]
Benchmark #1: ./t5310-pack-bitmaps.sh --root=/var/ram/git-tests
Time (mean ± σ): 2.210 s ± 0.174 s [User: 2.570 s, System: 0.604 s]
Range (min … max): 1.999 s … 2.590 s 10 runs
So we're over 20% faster, while making the callers slightly shorter. We
added a lot more lines in test-lib-function.sh, of course, and the
helper is way more featureful than we need here. But my hope is that it
will be flexible enough to use in more places.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-02 05:16:49 +00:00
|
|
|
then
|
|
|
|
add_from=t
|
|
|
|
fi
|
|
|
|
|
|
|
|
while test "$total" -gt 0
|
|
|
|
do
|
|
|
|
test_tick &&
|
|
|
|
echo "commit $ref"
|
|
|
|
printf 'author %s <%s> %s\n' \
|
|
|
|
"$GIT_AUTHOR_NAME" \
|
|
|
|
"$GIT_AUTHOR_EMAIL" \
|
|
|
|
"$GIT_AUTHOR_DATE"
|
|
|
|
printf 'committer %s <%s> %s\n' \
|
|
|
|
"$GIT_COMMITTER_NAME" \
|
|
|
|
"$GIT_COMMITTER_EMAIL" \
|
|
|
|
"$GIT_COMMITTER_DATE"
|
|
|
|
echo "data <<EOF"
|
|
|
|
printf "$message\n" $n
|
|
|
|
echo "EOF"
|
|
|
|
if test -n "$add_from"
|
|
|
|
then
|
|
|
|
echo "from $ref^0"
|
|
|
|
add_from=
|
|
|
|
fi
|
|
|
|
printf "M 644 inline $filename\n" $n
|
|
|
|
echo "data <<EOF"
|
|
|
|
printf "$contents\n" $n
|
|
|
|
echo "EOF"
|
|
|
|
echo
|
|
|
|
n=$((n + 1))
|
|
|
|
total=$((total - 1))
|
|
|
|
done >"$tmpfile"
|
|
|
|
|
|
|
|
git -C "$indir" \
|
|
|
|
-c fastimport.unpacklimit=0 \
|
|
|
|
fast-import <"$tmpfile" || return 1
|
|
|
|
|
|
|
|
# This will be left in place on failure, which may aid debugging.
|
|
|
|
rm -f "$tmpfile"
|
|
|
|
|
|
|
|
# If we updated HEAD, then be nice and update the index and working
|
|
|
|
# tree, too.
|
|
|
|
if test "$ref" = "HEAD"
|
|
|
|
then
|
|
|
|
git -C "$indir" checkout -f HEAD || return 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2012-02-17 10:25:08 +00:00
|
|
|
# This function helps systems where core.filemode=false is set.
|
|
|
|
# Use it instead of plain 'chmod +x' to set or unset the executable bit
|
|
|
|
# of a file in the working directory and add it to the index.
|
|
|
|
|
|
|
|
test_chmod () {
|
|
|
|
chmod "$@" &&
|
|
|
|
git update-index --add "--chmod=$@"
|
|
|
|
}
|
|
|
|
|
2021-01-05 15:47:39 +00:00
|
|
|
# Get the modebits from a file or directory, ignoring the setgid bit (g+s).
|
|
|
|
# This bit is inherited by subdirectories at their creation. So we remove it
|
|
|
|
# from the returning string to prevent callers from having to worry about the
|
|
|
|
# state of the bit in the test directory.
|
|
|
|
#
|
2017-06-25 04:34:28 +00:00
|
|
|
test_modebits () {
|
2021-01-05 15:47:39 +00:00
|
|
|
ls -ld "$1" | sed -e 's|^\(..........\).*|\1|' \
|
|
|
|
-e 's|^\(......\)S|\1-|' -e 's|^\(......\)s|\1x|'
|
2017-06-25 04:34:28 +00:00
|
|
|
}
|
|
|
|
|
2012-02-17 10:25:08 +00:00
|
|
|
# Unset a configuration variable, but don't fail if it doesn't exist.
|
|
|
|
test_unconfig () {
|
2015-09-05 13:12:47 +00:00
|
|
|
config_dir=
|
|
|
|
if test "$1" = -C
|
|
|
|
then
|
|
|
|
shift
|
|
|
|
config_dir=$1
|
|
|
|
shift
|
|
|
|
fi
|
|
|
|
git ${config_dir:+-C "$config_dir"} config --unset-all "$@"
|
2012-02-17 10:25:08 +00:00
|
|
|
config_status=$?
|
|
|
|
case "$config_status" in
|
|
|
|
5) # ok, nothing to unset
|
|
|
|
config_status=0
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
return $config_status
|
|
|
|
}
|
|
|
|
|
|
|
|
# Set git config, automatically unsetting it after the test is over.
|
|
|
|
test_config () {
|
2015-09-05 13:12:47 +00:00
|
|
|
config_dir=
|
|
|
|
if test "$1" = -C
|
|
|
|
then
|
|
|
|
shift
|
|
|
|
config_dir=$1
|
|
|
|
shift
|
|
|
|
fi
|
config: use gitdir to get worktree config
Update 'do_git_config_sequence()' to read the worktree config from
'config.worktree' in 'opts->git_dir' rather than the gitdir of
'the_repository'.
The worktree config is loaded from the path returned by
'git_pathdup("config.worktree")', the 'config.worktree' relative to the
gitdir of 'the_repository'. If loading the config for a submodule, this path
is incorrect, since 'the_repository' is the superproject. 'opts->git_dir' is
the gitdir of the submodule being configured, so the config file in that
location should be read instead.
To ensure the use of 'opts->git_dir' is safe, require that 'opts->git_dir'
is set if-and-only-if 'opts->commondir' is set (rather than "only-if" as it
is now). In all current usage of 'config_options', these values are set
together, so the stricter check does not change any behavior.
Finally, add tests to 't3007-ls-files-recurse-submodules.sh' to verify the
corrected config is loaded. Use 'ls-files' to test this because, unlike some
other '--recurse-submodules' commands, 'ls-files' parses the config of the
submodule in the same process as the superproject (via 'show_submodule()' ->
'repo_read_index()' -> 'prepare_repo_settings()'). As a result,
'the_repository' points to the config of the superproject but the
commondir/gitdir in the config sequence will be that of the submodule,
providing the exact scenario needed to verify this patch.
The first test ('--recurse-submodules parses submodule repo config') checks
that the submodule's *repo* config is read when running 'ls-files' on the
superproject; this confirms already-working behavior, serving as a reference
for how worktree config parsing should behave. The second test
('--recurse-submodules parses submodule worktree config') tests the same
scenario as the previous but instead using the *worktree* config,
demonstrating the corrected behavior. The 'test_config' helper is extended
for this case so that it properly applies the '--worktree' option to the
configure/unconfigure operations it performs.
Note that, although the submodule worktree config is now parsed instead of
the superproject's, 'extensions.worktreeConfig' in the superproject still
controls whether or not the worktree config is enabled at all in the
submodule. This will be fixed in a later patch.
Signed-off-by: Victoria Dye <vdye@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-26 01:32:58 +00:00
|
|
|
|
|
|
|
# If --worktree is provided, use it to configure/unconfigure
|
|
|
|
is_worktree=
|
|
|
|
if test "$1" = --worktree
|
|
|
|
then
|
|
|
|
is_worktree=1
|
|
|
|
shift
|
|
|
|
fi
|
|
|
|
|
|
|
|
test_when_finished "test_unconfig ${config_dir:+-C '$config_dir'} ${is_worktree:+--worktree} '$1'" &&
|
|
|
|
git ${config_dir:+-C "$config_dir"} config ${is_worktree:+--worktree} "$@"
|
2012-02-17 10:25:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
test_config_global () {
|
|
|
|
test_when_finished "test_unconfig --global '$1'" &&
|
|
|
|
git config --global "$@"
|
|
|
|
}
|
|
|
|
|
|
|
|
write_script () {
|
|
|
|
{
|
|
|
|
echo "#!${2-"$SHELL_PATH"}" &&
|
|
|
|
cat
|
|
|
|
} >"$1" &&
|
|
|
|
chmod +x "$1"
|
|
|
|
}
|
|
|
|
|
2022-03-17 10:13:06 +00:00
|
|
|
# Usage: test_hook [options] <hook-name> <<-\EOF
|
|
|
|
#
|
|
|
|
# -C <dir>:
|
|
|
|
# Run all git commands in directory <dir>
|
|
|
|
# --setup
|
|
|
|
# Setup a hook for subsequent tests, i.e. don't remove it in a
|
|
|
|
# "test_when_finished"
|
|
|
|
# --clobber
|
|
|
|
# Overwrite an existing <hook-name>, if it exists. Implies
|
|
|
|
# --setup (i.e. the "test_when_finished" is assumed to have been
|
|
|
|
# set up already).
|
2022-03-17 10:13:16 +00:00
|
|
|
# --disable
|
|
|
|
# Disable (chmod -x) an existing <hook-name>, which must exist.
|
|
|
|
# --remove
|
|
|
|
# Remove (rm -f) an existing <hook-name>, which must exist.
|
2022-03-17 10:13:06 +00:00
|
|
|
test_hook () {
|
|
|
|
setup= &&
|
|
|
|
clobber= &&
|
2022-03-17 10:13:16 +00:00
|
|
|
disable= &&
|
|
|
|
remove= &&
|
2022-03-17 10:13:06 +00:00
|
|
|
indir= &&
|
|
|
|
while test $# != 0
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
-C)
|
|
|
|
indir="$2" &&
|
|
|
|
shift
|
|
|
|
;;
|
|
|
|
--setup)
|
|
|
|
setup=t
|
|
|
|
;;
|
|
|
|
--clobber)
|
|
|
|
clobber=t
|
|
|
|
;;
|
2022-03-17 10:13:16 +00:00
|
|
|
--disable)
|
|
|
|
disable=t
|
|
|
|
;;
|
|
|
|
--remove)
|
|
|
|
remove=t
|
|
|
|
;;
|
2022-03-17 10:13:06 +00:00
|
|
|
-*)
|
|
|
|
BUG "invalid argument: $1"
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
esac &&
|
|
|
|
shift
|
|
|
|
done &&
|
|
|
|
|
|
|
|
git_dir=$(git -C "$indir" rev-parse --absolute-git-dir) &&
|
|
|
|
hook_dir="$git_dir/hooks" &&
|
|
|
|
hook_file="$hook_dir/$1" &&
|
2022-03-17 10:13:16 +00:00
|
|
|
if test -n "$disable$remove"
|
|
|
|
then
|
|
|
|
test_path_is_file "$hook_file" &&
|
|
|
|
if test -n "$disable"
|
|
|
|
then
|
|
|
|
chmod -x "$hook_file"
|
|
|
|
elif test -n "$remove"
|
|
|
|
then
|
|
|
|
rm -f "$hook_file"
|
|
|
|
fi &&
|
|
|
|
return 0
|
|
|
|
fi &&
|
2022-03-17 10:13:06 +00:00
|
|
|
if test -z "$clobber"
|
|
|
|
then
|
|
|
|
test_path_is_missing "$hook_file"
|
|
|
|
fi &&
|
|
|
|
if test -z "$setup$clobber"
|
|
|
|
then
|
|
|
|
test_when_finished "rm \"$hook_file\""
|
|
|
|
fi &&
|
|
|
|
write_script "$hook_file"
|
|
|
|
}
|
|
|
|
|
2012-02-17 10:25:08 +00:00
|
|
|
# Use test_set_prereq to tell that a particular prerequisite is available.
|
|
|
|
# The prerequisite can later be checked for in two ways:
|
|
|
|
#
|
|
|
|
# - Explicitly using test_have_prereq.
|
|
|
|
#
|
|
|
|
# - Implicitly by specifying the prerequisite tag in the calls to
|
test-lib: simplify by removing test_external
Remove the "test_external" function added in [1]. This arguably makes
the output of t9700-perl-git.sh and friends worse. But as we'll argue
below the trade-off is worth it, since "chaining" to another TAP
emitter in test-lib.sh is more trouble than it's worth.
The new output of t9700-perl-git.sh is now:
$ ./t9700-perl-git.sh
ok 1 - set up test repository
ok 2 - use t9700/test.pl to test Git.pm
# passed all 2 test(s)
1..2
Whereas before this change it would be:
$ ./t9700-perl-git.sh
ok 1 - set up test repository
# run 1: Perl API (perl /home/avar/g/git/t/t9700/test.pl)
ok 2 - use Git;
[... omitting tests 3..46 from t/t9700/test.pl ...]
ok 47 - unquote escape sequences
1..47
# test_external test Perl API was ok
# test_external_without_stderr test no stderr: Perl API was ok
At the time of its addition supporting "test_external" was easy, but
when test-lib.sh itself started to emit TAP in [2] we needed to make
everything surrounding the emission of the plan consider
"test_external". I added that support in [2] so that we could run:
prove ./t9700-perl-git.sh :: -v
But since then in [3] the door has been closed on combining
$HARNESS_ACTIVE and -v, we'll now just die:
$ prove ./t9700-perl-git.sh :: -v
Bailout called. Further testing stopped: verbose mode forbidden under TAP harness; try --verbose-log
FAILED--Further testing stopped: verbose mode forbidden under TAP harness; try --verbose-log
So the only use of this has been that *if* we had failure in one of
these tests we could e.g. in CI see which test failed based on the
test number. Now we'll need to look at the full verbose logs to get
that same information.
I think this trade-off is acceptable given the reduction in
complexity, and it brings these tests in line with other similar
tests, e.g. the reftable tests added in [4] will be condensed down to
just one test, which invokes the C helper:
$ ./t0032-reftable-unittest.sh
ok 1 - unittests
# passed all 1 test(s)
1..1
It would still be nice to have that ":: -v" form work again, it
never *really* worked, but even though we've had edge cases test
output screwing up the TAP it mostly worked between d998bd4ab67 and
[3], so we may have been overzealous in forbidding it outright.
I have local patches which I'm planning to submit sooner than later
that get us to that goal, and in a way that isn't buggy. In the
meantime getting rid of this special case makes hacking on this area
of test-lib.sh easier, as we'll do in subsequent commits.
The switch from "perl" to "$PERL_PATH" here is because "perl" is
defined as a shell function in the test suite, see a5bf824f3b4 (t:
prevent '-x' tracing from interfering with test helpers' stderr,
2018-02-25). On e.g. the OSX CI the "command perl"... will be part of
the emitted stderr.
1. fb32c410087 (t/test-lib.sh: add test_external and
test_external_without_stderr, 2008-06-19)
2. d998bd4ab67 (test-lib: Make the test_external_* functions
TAP-aware, 2010-06-24)
3. 614fe015212 (test-lib: bail out when "-v" used under
"prove", 2016-10-22)
4. ef8a6c62687 (reftable: utility functions, 2021-10-07)
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-07-27 23:13:37 +00:00
|
|
|
# test_expect_{success,failure}
|
2012-02-17 10:25:08 +00:00
|
|
|
#
|
|
|
|
# The single parameter is the prerequisite tag (a simple word, in all
|
|
|
|
# capital letters by convention).
|
|
|
|
|
2018-04-28 22:33:36 +00:00
|
|
|
test_unset_prereq () {
|
|
|
|
! test_have_prereq "$1" ||
|
|
|
|
satisfied_prereq="${satisfied_prereq% $1 *} ${satisfied_prereq#* $1 }"
|
|
|
|
}
|
|
|
|
|
2012-02-17 10:25:08 +00:00
|
|
|
test_set_prereq () {
|
2019-06-21 10:18:12 +00:00
|
|
|
if test -n "$GIT_TEST_FAIL_PREREQS_INTERNAL"
|
2019-05-13 18:32:42 +00:00
|
|
|
then
|
|
|
|
case "$1" in
|
|
|
|
# The "!" case is handled below with
|
|
|
|
# test_unset_prereq()
|
|
|
|
!*)
|
|
|
|
;;
|
2022-07-19 18:32:16 +00:00
|
|
|
# List of things we can't easily pretend to not support
|
2019-05-13 18:32:42 +00:00
|
|
|
SYMLINKS)
|
|
|
|
;;
|
|
|
|
# Inspecting whether GIT_TEST_FAIL_PREREQS is on
|
|
|
|
# should be unaffected.
|
|
|
|
FAIL_PREREQS)
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
return
|
|
|
|
esac
|
|
|
|
fi
|
|
|
|
|
2018-04-28 22:33:36 +00:00
|
|
|
case "$1" in
|
|
|
|
!*)
|
|
|
|
test_unset_prereq "${1#!}"
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
satisfied_prereq="$satisfied_prereq$1 "
|
|
|
|
;;
|
|
|
|
esac
|
2012-02-17 10:25:08 +00:00
|
|
|
}
|
2012-07-26 20:57:56 +00:00
|
|
|
satisfied_prereq=" "
|
2012-07-26 22:50:45 +00:00
|
|
|
lazily_testable_prereq= lazily_tested_prereq=
|
|
|
|
|
|
|
|
# Usage: test_lazy_prereq PREREQ 'script'
|
|
|
|
test_lazy_prereq () {
|
|
|
|
lazily_testable_prereq="$lazily_testable_prereq$1 "
|
|
|
|
eval test_prereq_lazily_$1=\$2
|
|
|
|
}
|
|
|
|
|
|
|
|
test_run_lazy_prereq_ () {
|
|
|
|
script='
|
tests: make sure nested lazy prereqs work reliably
Some test prereqs depend on other prereqs, so in a couple of cases we
have nested prereqs that look something like this:
test_lazy_prereq FOO '
test_have_prereq BAR &&
check-foo
'
This can be problematic, because lazy prereqs are evaluated in the
'$TRASH_DIRECTORY/prereq-test-dir' directory, which is the same for
every prereq, and which is automatically removed after the prereq has
been evaluated. So if the inner prereq (BAR above) is a lazy prereq
that hasn't been evaluated yet, then after its evaluation the
'prereq-test-dir' shared with the outer prereq will be removed.
Consequently, 'check-foo' will find itself in a non-existing
directory, and won't be able to create/access any files in its cwd,
which could result in an unfulfilled outer prereq.
Luckily, this doesn't affect any of our current nested prereqs, either
because the inner prereq is not a lazy prereq (e.g. MINGW, CYGWIN or
PERL), or because the outer prereq happens to be checked without
touching any paths in its cwd (GPGSM and RFC1991 in 'lib-gpg.sh').
So to prevent nested prereqs from interfering with each other let's
evaluate each prereq in its own dedicated directory by appending the
prereq's name to the directory name, e.g. 'prereq-test-dir-SYMLINKS'.
In the test we check not only that the prereq test dir is still there,
but also that the inner prereq can't mess with the outer prereq's
files.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-18 19:04:13 +00:00
|
|
|
mkdir -p "$TRASH_DIRECTORY/prereq-test-dir-'"$1"'" &&
|
2012-07-26 22:50:45 +00:00
|
|
|
(
|
tests: make sure nested lazy prereqs work reliably
Some test prereqs depend on other prereqs, so in a couple of cases we
have nested prereqs that look something like this:
test_lazy_prereq FOO '
test_have_prereq BAR &&
check-foo
'
This can be problematic, because lazy prereqs are evaluated in the
'$TRASH_DIRECTORY/prereq-test-dir' directory, which is the same for
every prereq, and which is automatically removed after the prereq has
been evaluated. So if the inner prereq (BAR above) is a lazy prereq
that hasn't been evaluated yet, then after its evaluation the
'prereq-test-dir' shared with the outer prereq will be removed.
Consequently, 'check-foo' will find itself in a non-existing
directory, and won't be able to create/access any files in its cwd,
which could result in an unfulfilled outer prereq.
Luckily, this doesn't affect any of our current nested prereqs, either
because the inner prereq is not a lazy prereq (e.g. MINGW, CYGWIN or
PERL), or because the outer prereq happens to be checked without
touching any paths in its cwd (GPGSM and RFC1991 in 'lib-gpg.sh').
So to prevent nested prereqs from interfering with each other let's
evaluate each prereq in its own dedicated directory by appending the
prereq's name to the directory name, e.g. 'prereq-test-dir-SYMLINKS'.
In the test we check not only that the prereq test dir is still there,
but also that the inner prereq can't mess with the outer prereq's
files.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-18 19:04:13 +00:00
|
|
|
cd "$TRASH_DIRECTORY/prereq-test-dir-'"$1"'" &&'"$2"'
|
2012-07-26 22:50:45 +00:00
|
|
|
)'
|
|
|
|
say >&3 "checking prerequisite: $1"
|
|
|
|
say >&3 "$script"
|
|
|
|
test_eval_ "$script"
|
|
|
|
eval_ret=$?
|
tests: make sure nested lazy prereqs work reliably
Some test prereqs depend on other prereqs, so in a couple of cases we
have nested prereqs that look something like this:
test_lazy_prereq FOO '
test_have_prereq BAR &&
check-foo
'
This can be problematic, because lazy prereqs are evaluated in the
'$TRASH_DIRECTORY/prereq-test-dir' directory, which is the same for
every prereq, and which is automatically removed after the prereq has
been evaluated. So if the inner prereq (BAR above) is a lazy prereq
that hasn't been evaluated yet, then after its evaluation the
'prereq-test-dir' shared with the outer prereq will be removed.
Consequently, 'check-foo' will find itself in a non-existing
directory, and won't be able to create/access any files in its cwd,
which could result in an unfulfilled outer prereq.
Luckily, this doesn't affect any of our current nested prereqs, either
because the inner prereq is not a lazy prereq (e.g. MINGW, CYGWIN or
PERL), or because the outer prereq happens to be checked without
touching any paths in its cwd (GPGSM and RFC1991 in 'lib-gpg.sh').
So to prevent nested prereqs from interfering with each other let's
evaluate each prereq in its own dedicated directory by appending the
prereq's name to the directory name, e.g. 'prereq-test-dir-SYMLINKS'.
In the test we check not only that the prereq test dir is still there,
but also that the inner prereq can't mess with the outer prereq's
files.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-18 19:04:13 +00:00
|
|
|
rm -rf "$TRASH_DIRECTORY/prereq-test-dir-$1"
|
2012-07-26 22:50:45 +00:00
|
|
|
if test "$eval_ret" = 0; then
|
|
|
|
say >&3 "prerequisite $1 ok"
|
|
|
|
else
|
|
|
|
say >&3 "prerequisite $1 not satisfied"
|
|
|
|
fi
|
|
|
|
return $eval_ret
|
|
|
|
}
|
2012-02-17 10:25:08 +00:00
|
|
|
|
|
|
|
test_have_prereq () {
|
|
|
|
# prerequisites can be concatenated with ','
|
|
|
|
save_IFS=$IFS
|
|
|
|
IFS=,
|
|
|
|
set -- $*
|
|
|
|
IFS=$save_IFS
|
|
|
|
|
|
|
|
total_prereq=0
|
|
|
|
ok_prereq=0
|
|
|
|
missing_prereq=
|
|
|
|
|
|
|
|
for prerequisite
|
|
|
|
do
|
2012-11-15 00:33:25 +00:00
|
|
|
case "$prerequisite" in
|
|
|
|
!*)
|
|
|
|
negative_prereq=t
|
|
|
|
prerequisite=${prerequisite#!}
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
negative_prereq=
|
|
|
|
esac
|
|
|
|
|
2012-07-26 22:50:45 +00:00
|
|
|
case " $lazily_tested_prereq " in
|
|
|
|
*" $prerequisite "*)
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
case " $lazily_testable_prereq " in
|
|
|
|
*" $prerequisite "*)
|
|
|
|
eval "script=\$test_prereq_lazily_$prerequisite" &&
|
|
|
|
if test_run_lazy_prereq_ "$prerequisite" "$script"
|
|
|
|
then
|
|
|
|
test_set_prereq $prerequisite
|
|
|
|
fi
|
|
|
|
lazily_tested_prereq="$lazily_tested_prereq$prerequisite "
|
|
|
|
esac
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
2012-02-17 10:25:08 +00:00
|
|
|
total_prereq=$(($total_prereq + 1))
|
2012-07-26 20:57:56 +00:00
|
|
|
case "$satisfied_prereq" in
|
2012-02-17 10:25:08 +00:00
|
|
|
*" $prerequisite "*)
|
2012-11-15 00:33:25 +00:00
|
|
|
satisfied_this_prereq=t
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
satisfied_this_prereq=
|
|
|
|
esac
|
|
|
|
|
|
|
|
case "$satisfied_this_prereq,$negative_prereq" in
|
|
|
|
t,|,t)
|
2012-02-17 10:25:08 +00:00
|
|
|
ok_prereq=$(($ok_prereq + 1))
|
|
|
|
;;
|
|
|
|
*)
|
2012-11-15 00:33:25 +00:00
|
|
|
# Keep a list of missing prerequisites; restore
|
|
|
|
# the negative marker if necessary.
|
|
|
|
prerequisite=${negative_prereq:+!}$prerequisite
|
2021-11-20 15:04:00 +00:00
|
|
|
|
|
|
|
# Abort if this prereq was marked as required
|
|
|
|
if test -n "$GIT_TEST_REQUIRE_PREREQ"
|
|
|
|
then
|
|
|
|
case " $GIT_TEST_REQUIRE_PREREQ " in
|
|
|
|
*" $prerequisite "*)
|
|
|
|
BAIL_OUT "required prereq $prerequisite failed"
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
fi
|
|
|
|
|
2012-02-17 10:25:08 +00:00
|
|
|
if test -z "$missing_prereq"
|
|
|
|
then
|
|
|
|
missing_prereq=$prerequisite
|
|
|
|
else
|
|
|
|
missing_prereq="$prerequisite,$missing_prereq"
|
|
|
|
fi
|
|
|
|
esac
|
|
|
|
done
|
|
|
|
|
|
|
|
test $total_prereq = $ok_prereq
|
|
|
|
}
|
|
|
|
|
|
|
|
test_declared_prereq () {
|
|
|
|
case ",$test_prereq," in
|
|
|
|
*,$1,*)
|
|
|
|
return 0
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
return 1
|
|
|
|
}
|
|
|
|
|
2015-04-26 22:18:45 +00:00
|
|
|
test_verify_prereq () {
|
|
|
|
test -z "$test_prereq" ||
|
|
|
|
expr >/dev/null "$test_prereq" : '[A-Z0-9_,!]*$' ||
|
tests: send "bug in the test script" errors to the script's stderr
Some of the functions in our test library check that they were invoked
properly with conditions like this:
test "$#" = 2 ||
error "bug in the test script: not 2 parameters to test-expect-success"
If this particular condition is triggered, then 'error' will abort the
whole test script with a bold red error message [1] right away.
However, under certain circumstances the test script will be aborted
completely silently, namely if:
- a similar condition in a test helper function like
'test_line_count' is triggered,
- which is invoked from the test script's "main" shell [2],
- and the test script is run manually (i.e. './t1234-foo.sh' as
opposed to 'make t1234-foo.sh' or 'make test') [3]
- and without the '--verbose' option,
because the error message is printed from within 'test_eval_', where
standard output is redirected either to /dev/null or to a log file.
The only indication that something is wrong is that not all tests in
the script are executed and at the end of the test script's output
there is no "# passed all N tests" message, which are subtle and can
easily go unnoticed, as I had to experience myself.
Send these "bug in the test script" error messages directly to the
test scripts standard error and thus to the terminal, so those bugs
will be much harder to overlook. Instead of updating all ~20 such
'error' calls with a redirection, let's add a BUG() function to
'test-lib.sh', wrapping an 'error' call with the proper redirection
and also including the common prefix of those error messages, and
convert all those call sites [4] to use this new BUG() function
instead.
[1] That particular error message from 'test_expect_success' is
printed in color only when running with or without '--verbose';
with '--tee' or '--verbose-log' the error is printed without
color, but it is printed to the terminal nonetheless.
[2] If such a condition is triggered in a subshell of a test, then
'error' won't be able to abort the whole test script, but only the
subshell, which in turn causes the test to fail in the usual way,
indicating loudly and clearly that something is wrong.
[3] Well, 'error' aborts the test script the same way when run
manually or by 'make' or 'prove', but both 'make' and 'prove' pay
attention to the test script's exit status, and even a silently
aborted test script would then trigger those tools' usual
noticable error messages.
[4] Strictly speaking, not all those 'error' calls need that
redirection to send their output to the terminal, see e.g.
'test_expect_success' in the opening example, but I think it's
better to be consistent.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-19 13:13:26 +00:00
|
|
|
BUG "'$test_prereq' does not look like a prereq"
|
2015-04-26 22:18:45 +00:00
|
|
|
}
|
|
|
|
|
2012-02-17 10:25:08 +00:00
|
|
|
test_expect_failure () {
|
2022-05-21 22:18:51 +00:00
|
|
|
test_start_ "$@"
|
2012-02-17 10:25:08 +00:00
|
|
|
test "$#" = 3 && { test_prereq=$1; shift; } || test_prereq=
|
|
|
|
test "$#" = 2 ||
|
tests: send "bug in the test script" errors to the script's stderr
Some of the functions in our test library check that they were invoked
properly with conditions like this:
test "$#" = 2 ||
error "bug in the test script: not 2 parameters to test-expect-success"
If this particular condition is triggered, then 'error' will abort the
whole test script with a bold red error message [1] right away.
However, under certain circumstances the test script will be aborted
completely silently, namely if:
- a similar condition in a test helper function like
'test_line_count' is triggered,
- which is invoked from the test script's "main" shell [2],
- and the test script is run manually (i.e. './t1234-foo.sh' as
opposed to 'make t1234-foo.sh' or 'make test') [3]
- and without the '--verbose' option,
because the error message is printed from within 'test_eval_', where
standard output is redirected either to /dev/null or to a log file.
The only indication that something is wrong is that not all tests in
the script are executed and at the end of the test script's output
there is no "# passed all N tests" message, which are subtle and can
easily go unnoticed, as I had to experience myself.
Send these "bug in the test script" error messages directly to the
test scripts standard error and thus to the terminal, so those bugs
will be much harder to overlook. Instead of updating all ~20 such
'error' calls with a redirection, let's add a BUG() function to
'test-lib.sh', wrapping an 'error' call with the proper redirection
and also including the common prefix of those error messages, and
convert all those call sites [4] to use this new BUG() function
instead.
[1] That particular error message from 'test_expect_success' is
printed in color only when running with or without '--verbose';
with '--tee' or '--verbose-log' the error is printed without
color, but it is printed to the terminal nonetheless.
[2] If such a condition is triggered in a subshell of a test, then
'error' won't be able to abort the whole test script, but only the
subshell, which in turn causes the test to fail in the usual way,
indicating loudly and clearly that something is wrong.
[3] Well, 'error' aborts the test script the same way when run
manually or by 'make' or 'prove', but both 'make' and 'prove' pay
attention to the test script's exit status, and even a silently
aborted test script would then trigger those tools' usual
noticable error messages.
[4] Strictly speaking, not all those 'error' calls need that
redirection to send their output to the terminal, see e.g.
'test_expect_success' in the opening example, but I think it's
better to be consistent.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-19 13:13:26 +00:00
|
|
|
BUG "not 2 or 3 parameters to test-expect-failure"
|
2015-04-26 22:18:45 +00:00
|
|
|
test_verify_prereq
|
2012-02-17 10:25:08 +00:00
|
|
|
export test_prereq
|
|
|
|
if ! test_skip "$@"
|
|
|
|
then
|
2022-05-21 22:18:53 +00:00
|
|
|
test -n "$test_skip_test_preamble" ||
|
2019-08-05 21:04:47 +00:00
|
|
|
say >&3 "checking known breakage of $TEST_NUMBER.$test_count '$1': $2"
|
2012-02-17 10:25:08 +00:00
|
|
|
if test_run_ "$2" expecting_failure
|
|
|
|
then
|
|
|
|
test_known_broken_ok_ "$1"
|
|
|
|
else
|
|
|
|
test_known_broken_failure_ "$1"
|
|
|
|
fi
|
|
|
|
fi
|
2013-06-18 12:25:59 +00:00
|
|
|
test_finish_
|
2012-02-17 10:25:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
test_expect_success () {
|
2022-05-21 22:18:51 +00:00
|
|
|
test_start_ "$@"
|
2012-02-17 10:25:08 +00:00
|
|
|
test "$#" = 3 && { test_prereq=$1; shift; } || test_prereq=
|
|
|
|
test "$#" = 2 ||
|
tests: send "bug in the test script" errors to the script's stderr
Some of the functions in our test library check that they were invoked
properly with conditions like this:
test "$#" = 2 ||
error "bug in the test script: not 2 parameters to test-expect-success"
If this particular condition is triggered, then 'error' will abort the
whole test script with a bold red error message [1] right away.
However, under certain circumstances the test script will be aborted
completely silently, namely if:
- a similar condition in a test helper function like
'test_line_count' is triggered,
- which is invoked from the test script's "main" shell [2],
- and the test script is run manually (i.e. './t1234-foo.sh' as
opposed to 'make t1234-foo.sh' or 'make test') [3]
- and without the '--verbose' option,
because the error message is printed from within 'test_eval_', where
standard output is redirected either to /dev/null or to a log file.
The only indication that something is wrong is that not all tests in
the script are executed and at the end of the test script's output
there is no "# passed all N tests" message, which are subtle and can
easily go unnoticed, as I had to experience myself.
Send these "bug in the test script" error messages directly to the
test scripts standard error and thus to the terminal, so those bugs
will be much harder to overlook. Instead of updating all ~20 such
'error' calls with a redirection, let's add a BUG() function to
'test-lib.sh', wrapping an 'error' call with the proper redirection
and also including the common prefix of those error messages, and
convert all those call sites [4] to use this new BUG() function
instead.
[1] That particular error message from 'test_expect_success' is
printed in color only when running with or without '--verbose';
with '--tee' or '--verbose-log' the error is printed without
color, but it is printed to the terminal nonetheless.
[2] If such a condition is triggered in a subshell of a test, then
'error' won't be able to abort the whole test script, but only the
subshell, which in turn causes the test to fail in the usual way,
indicating loudly and clearly that something is wrong.
[3] Well, 'error' aborts the test script the same way when run
manually or by 'make' or 'prove', but both 'make' and 'prove' pay
attention to the test script's exit status, and even a silently
aborted test script would then trigger those tools' usual
noticable error messages.
[4] Strictly speaking, not all those 'error' calls need that
redirection to send their output to the terminal, see e.g.
'test_expect_success' in the opening example, but I think it's
better to be consistent.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-19 13:13:26 +00:00
|
|
|
BUG "not 2 or 3 parameters to test-expect-success"
|
2015-04-26 22:18:45 +00:00
|
|
|
test_verify_prereq
|
2012-02-17 10:25:08 +00:00
|
|
|
export test_prereq
|
|
|
|
if ! test_skip "$@"
|
|
|
|
then
|
2022-05-21 22:18:53 +00:00
|
|
|
test -n "$test_skip_test_preamble" ||
|
2019-08-05 21:04:47 +00:00
|
|
|
say >&3 "expecting success of $TEST_NUMBER.$test_count '$1': $2"
|
2012-02-17 10:25:08 +00:00
|
|
|
if test_run_ "$2"
|
|
|
|
then
|
|
|
|
test_ok_ "$1"
|
|
|
|
else
|
|
|
|
test_failure_ "$@"
|
|
|
|
fi
|
|
|
|
fi
|
2013-06-18 12:25:59 +00:00
|
|
|
test_finish_
|
2012-02-17 10:25:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
# debugging-friendly alternatives to "test [-f|-d|-e]"
|
2021-02-12 13:29:41 +00:00
|
|
|
# The commands test the existence or non-existence of $1
|
2012-02-17 10:25:08 +00:00
|
|
|
test_path_is_file () {
|
2021-02-12 13:29:41 +00:00
|
|
|
test "$#" -ne 1 && BUG "1 param"
|
2014-10-15 08:35:21 +00:00
|
|
|
if ! test -f "$1"
|
2012-02-17 10:25:08 +00:00
|
|
|
then
|
2021-02-12 13:29:41 +00:00
|
|
|
echo "File $1 doesn't exist"
|
2012-02-17 10:25:08 +00:00
|
|
|
false
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2022-02-22 21:54:29 +00:00
|
|
|
test_path_is_file_not_symlink () {
|
|
|
|
test "$#" -ne 1 && BUG "1 param"
|
|
|
|
test_path_is_file "$1" &&
|
|
|
|
if test -h "$1"
|
|
|
|
then
|
|
|
|
echo "$1 shouldn't be a symbolic link"
|
|
|
|
false
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2012-02-17 10:25:08 +00:00
|
|
|
test_path_is_dir () {
|
2021-02-12 13:29:42 +00:00
|
|
|
test "$#" -ne 1 && BUG "1 param"
|
2014-10-15 08:35:21 +00:00
|
|
|
if ! test -d "$1"
|
2012-02-17 10:25:08 +00:00
|
|
|
then
|
2021-02-12 13:29:41 +00:00
|
|
|
echo "Directory $1 doesn't exist"
|
2012-02-17 10:25:08 +00:00
|
|
|
false
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2022-02-22 21:54:29 +00:00
|
|
|
test_path_is_dir_not_symlink () {
|
|
|
|
test "$#" -ne 1 && BUG "1 param"
|
|
|
|
test_path_is_dir "$1" &&
|
|
|
|
if test -h "$1"
|
|
|
|
then
|
|
|
|
echo "$1 shouldn't be a symbolic link"
|
|
|
|
false
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2018-08-08 16:31:06 +00:00
|
|
|
test_path_exists () {
|
2021-02-12 13:29:41 +00:00
|
|
|
test "$#" -ne 1 && BUG "1 param"
|
2018-08-08 16:31:06 +00:00
|
|
|
if ! test -e "$1"
|
|
|
|
then
|
2021-02-12 13:29:41 +00:00
|
|
|
echo "Path $1 doesn't exist"
|
2018-08-08 16:31:06 +00:00
|
|
|
false
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2022-02-22 21:54:29 +00:00
|
|
|
test_path_is_symlink () {
|
|
|
|
test "$#" -ne 1 && BUG "1 param"
|
|
|
|
if ! test -h "$1"
|
|
|
|
then
|
|
|
|
echo "Symbolic link $1 doesn't exist"
|
|
|
|
false
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2023-06-27 16:18:56 +00:00
|
|
|
test_path_is_executable () {
|
|
|
|
test "$#" -ne 1 && BUG "1 param"
|
|
|
|
if ! test -x "$1"
|
|
|
|
then
|
|
|
|
echo "$1 is not executable"
|
|
|
|
false
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2014-06-19 20:12:23 +00:00
|
|
|
# Check if the directory exists and is empty as expected, barf otherwise.
|
|
|
|
test_dir_is_empty () {
|
2021-02-12 13:29:42 +00:00
|
|
|
test "$#" -ne 1 && BUG "1 param"
|
2014-06-19 20:12:23 +00:00
|
|
|
test_path_is_dir "$1" &&
|
2022-09-21 13:02:31 +00:00
|
|
|
if test -n "$(ls -a1 "$1" | grep -E -v '^\.\.?$')"
|
2014-06-19 20:12:23 +00:00
|
|
|
then
|
|
|
|
echo "Directory '$1' is not empty, it contains:"
|
|
|
|
ls -la "$1"
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2019-03-04 12:07:59 +00:00
|
|
|
# Check if the file exists and has a size greater than zero
|
|
|
|
test_file_not_empty () {
|
2021-02-12 13:29:42 +00:00
|
|
|
test "$#" = 2 && BUG "2 param"
|
2019-03-04 12:07:59 +00:00
|
|
|
if ! test -s "$1"
|
|
|
|
then
|
|
|
|
echo "'$1' is not a non-empty file."
|
|
|
|
false
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2012-02-17 10:25:08 +00:00
|
|
|
test_path_is_missing () {
|
2021-02-12 13:29:42 +00:00
|
|
|
test "$#" -ne 1 && BUG "1 param"
|
2014-10-15 08:35:21 +00:00
|
|
|
if test -e "$1"
|
2012-02-17 10:25:08 +00:00
|
|
|
then
|
|
|
|
echo "Path exists:"
|
|
|
|
ls -ld "$1"
|
|
|
|
false
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
|
|
|
# test_line_count checks that a file has the number of lines it
|
|
|
|
# ought to. For example:
|
|
|
|
#
|
|
|
|
# test_expect_success 'produce exactly one line of output' '
|
|
|
|
# do something >output &&
|
|
|
|
# test_line_count = 1 output
|
|
|
|
# '
|
|
|
|
#
|
|
|
|
# is like "test $(wc -l <output) = 1" except that it passes the
|
|
|
|
# output through when the number of lines is wrong.
|
|
|
|
|
|
|
|
test_line_count () {
|
|
|
|
if test $# != 3
|
|
|
|
then
|
tests: send "bug in the test script" errors to the script's stderr
Some of the functions in our test library check that they were invoked
properly with conditions like this:
test "$#" = 2 ||
error "bug in the test script: not 2 parameters to test-expect-success"
If this particular condition is triggered, then 'error' will abort the
whole test script with a bold red error message [1] right away.
However, under certain circumstances the test script will be aborted
completely silently, namely if:
- a similar condition in a test helper function like
'test_line_count' is triggered,
- which is invoked from the test script's "main" shell [2],
- and the test script is run manually (i.e. './t1234-foo.sh' as
opposed to 'make t1234-foo.sh' or 'make test') [3]
- and without the '--verbose' option,
because the error message is printed from within 'test_eval_', where
standard output is redirected either to /dev/null or to a log file.
The only indication that something is wrong is that not all tests in
the script are executed and at the end of the test script's output
there is no "# passed all N tests" message, which are subtle and can
easily go unnoticed, as I had to experience myself.
Send these "bug in the test script" error messages directly to the
test scripts standard error and thus to the terminal, so those bugs
will be much harder to overlook. Instead of updating all ~20 such
'error' calls with a redirection, let's add a BUG() function to
'test-lib.sh', wrapping an 'error' call with the proper redirection
and also including the common prefix of those error messages, and
convert all those call sites [4] to use this new BUG() function
instead.
[1] That particular error message from 'test_expect_success' is
printed in color only when running with or without '--verbose';
with '--tee' or '--verbose-log' the error is printed without
color, but it is printed to the terminal nonetheless.
[2] If such a condition is triggered in a subshell of a test, then
'error' won't be able to abort the whole test script, but only the
subshell, which in turn causes the test to fail in the usual way,
indicating loudly and clearly that something is wrong.
[3] Well, 'error' aborts the test script the same way when run
manually or by 'make' or 'prove', but both 'make' and 'prove' pay
attention to the test script's exit status, and even a silently
aborted test script would then trigger those tools' usual
noticable error messages.
[4] Strictly speaking, not all those 'error' calls need that
redirection to send their output to the terminal, see e.g.
'test_expect_success' in the opening example, but I think it's
better to be consistent.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-19 13:13:26 +00:00
|
|
|
BUG "not 3 parameters to test_line_count"
|
2012-02-17 10:25:08 +00:00
|
|
|
elif ! test $(wc -l <"$3") "$1" "$2"
|
|
|
|
then
|
|
|
|
echo "test_line_count: line count for $3 !$1 $2"
|
|
|
|
cat "$3"
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2021-07-04 05:46:10 +00:00
|
|
|
# SYNOPSIS:
|
|
|
|
# test_stdout_line_count <bin-ops> <value> <cmd> [<args>...]
|
|
|
|
#
|
|
|
|
# test_stdout_line_count checks that the output of a command has the number
|
|
|
|
# of lines it ought to. For example:
|
|
|
|
#
|
|
|
|
# test_stdout_line_count = 3 git ls-files -u
|
|
|
|
# test_stdout_line_count -gt 10 ls
|
|
|
|
test_stdout_line_count () {
|
|
|
|
local ops val trashdir &&
|
|
|
|
if test "$#" -le 3
|
|
|
|
then
|
|
|
|
BUG "expect 3 or more arguments"
|
|
|
|
fi &&
|
|
|
|
ops="$1" &&
|
|
|
|
val="$2" &&
|
|
|
|
shift 2 &&
|
|
|
|
if ! trashdir="$(git rev-parse --git-dir)/trash"; then
|
|
|
|
BUG "expect to be run inside a worktree"
|
|
|
|
fi &&
|
|
|
|
mkdir -p "$trashdir" &&
|
|
|
|
"$@" >"$trashdir/output" &&
|
|
|
|
test_line_count "$ops" "$val" "$trashdir/output"
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2020-11-07 01:12:57 +00:00
|
|
|
test_file_size () {
|
2021-02-12 13:29:42 +00:00
|
|
|
test "$#" -ne 1 && BUG "1 param"
|
2020-11-07 01:12:57 +00:00
|
|
|
test-tool path-utils file-size "$1"
|
|
|
|
}
|
|
|
|
|
2015-11-27 09:15:13 +00:00
|
|
|
# Returns success if a comma separated string of keywords ($1) contains a
|
|
|
|
# given keyword ($2).
|
|
|
|
# Examples:
|
|
|
|
# `list_contains "foo,bar" bar` returns 0
|
|
|
|
# `list_contains "foo" bar` returns 1
|
|
|
|
|
|
|
|
list_contains () {
|
|
|
|
case ",$1," in
|
|
|
|
*,$2,*)
|
|
|
|
return 0
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
return 1
|
|
|
|
}
|
|
|
|
|
2020-07-07 06:04:38 +00:00
|
|
|
# Returns success if the arguments indicate that a command should be
|
|
|
|
# accepted by test_must_fail(). If the command is run with env, the env
|
|
|
|
# and its corresponding variable settings will be stripped before we
|
|
|
|
# test the command being run.
|
|
|
|
test_must_fail_acceptable () {
|
|
|
|
if test "$1" = "env"
|
|
|
|
then
|
|
|
|
shift
|
|
|
|
while test $# -gt 0
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
*?=*)
|
|
|
|
shift
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
break
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
done
|
|
|
|
fi
|
|
|
|
|
|
|
|
case "$1" in
|
2023-01-27 20:06:01 +00:00
|
|
|
git|__git*|scalar|test-tool|test_terminal)
|
2020-07-07 06:04:38 +00:00
|
|
|
return 0
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
return 1
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
}
|
|
|
|
|
2012-02-17 10:25:08 +00:00
|
|
|
# This is not among top-level (test_expect_success | test_expect_failure)
|
|
|
|
# but is a prefix that can be used in the test script, like:
|
|
|
|
#
|
|
|
|
# test_expect_success 'complain and die' '
|
|
|
|
# do something &&
|
|
|
|
# do something else &&
|
|
|
|
# test_must_fail git checkout ../outerspace
|
|
|
|
# '
|
|
|
|
#
|
|
|
|
# Writing this as "! git checkout ../outerspace" is wrong, because
|
|
|
|
# the failure could be due to a segv. We want a controlled failure.
|
2018-02-09 02:42:33 +00:00
|
|
|
#
|
|
|
|
# Accepts the following options:
|
|
|
|
#
|
|
|
|
# ok=<signal-name>[,<...>]:
|
|
|
|
# Don't treat an exit caused by the given signal as error.
|
|
|
|
# Multiple signals can be specified as a comma separated list.
|
|
|
|
# Currently recognized signal names are: sigpipe, success.
|
|
|
|
# (Don't use 'success', use 'test_might_fail' instead.)
|
2020-07-07 06:04:38 +00:00
|
|
|
#
|
|
|
|
# Do not use this to run anything but "git" and other specific testable
|
|
|
|
# commands (see test_must_fail_acceptable()). We are not in the
|
|
|
|
# business of vetting system supplied commands -- in other words, this
|
|
|
|
# is wrong:
|
|
|
|
#
|
|
|
|
# test_must_fail grep pattern output
|
|
|
|
#
|
|
|
|
# Instead use '!':
|
|
|
|
#
|
|
|
|
# ! grep pattern output
|
2012-02-17 10:25:08 +00:00
|
|
|
|
|
|
|
test_must_fail () {
|
2015-11-27 09:15:13 +00:00
|
|
|
case "$1" in
|
|
|
|
ok=*)
|
|
|
|
_test_ok=${1#ok=}
|
|
|
|
shift
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
_test_ok=
|
|
|
|
;;
|
|
|
|
esac
|
2020-07-07 06:04:38 +00:00
|
|
|
if ! test_must_fail_acceptable "$@"
|
|
|
|
then
|
|
|
|
echo >&7 "test_must_fail: only 'git' is allowed: $*"
|
|
|
|
return 1
|
|
|
|
fi
|
t: prevent '-x' tracing from interfering with test helpers' stderr
Running a test script with '-x' turns on 'set -x' tracing, the output
of which is normally sent to stderr. This causes a lot of
test failures, because many tests redirect and verify the stderr
of shell functions, most frequently that of 'test_must_fail'.
These issues were worked around somewhat in d88785e424 (test-lib: set
BASH_XTRACEFD automatically, 2016-05-11), so at least we could
reliably run tests with '-x' tracing under a Bash version supporting
BASH_XTRACEFD, i.e. v4.1 and later.
Futhermore, redirecting the stderr of test helper functions like
'test_must_fail' or 'test_expect_code' is the cause of a different
issue as well. If these functions detect something unexpected, they
will write their error messages intended to the user to thier stderr.
However, if their stderr is redirected in order to save and verify the
stderr of the tested git command invoked in the function, then the
function's error messages will be redirected as well. Consequently,
those messages won't reach the user, making the test's verbose output
less useful.
This patch makes it safe to redirect and verify the stderr of those
test helper functions which are meant to run the tested command given
as argument, even when running tests with '-x' and /bin/sh. This is
achieved through a couple of file descriptor redirections:
- Duplicate stderr of the tested command executed in the test helper
function from the function's fd 7 (see next point), to ensure that
the tested command's error messages go to a different fd than the
'-x' trace of the commands executed in the function or the
function's error messages.
- Duplicate the test helper function's fd 7 from the function's
original stderr, meaning that, after taking a detour through fd 7,
the error messages of the tested command do end up on the
function's original stderr.
- Duplicate stderr of the test helper function from fd 4, i.e. the
fd connected to the test script's original stderr and the fd used
for BASH_XTRACEFD. This ensures that the '-x' trace of the
commands executed in the function
- doesn't go to the function's original stderr, so it won't mess
with callers who want to save and verify the tested command's
stderr.
- does go to the same fd independently from the shell running
the test script, be it /bin/sh, an older Bash without
BASH_XTRACEFD, or a more recent Bash already supporting
BASH_XTRACEFD.
Furthermore, this also makes sure that the function's error
messages go to this fd 4, meaning that the user will be able to
see them even if the function's stderr is redirected in the test.
- Specify the latter two redirections above in the test helper
function's definition, so they are performed every time the
function is invoked, without the need to modify the callsites of
the function.
Perform these redirections in those test helper functions which can be
expected to have their stderr redirected, i.e. in the functions
'test_must_fail', 'test_might_fail', 'test_expect_code', 'test_env',
'nongit', 'test_terminal' and 'perl'. Note that 'test_might_fail',
'test_env', and 'nongit' are not involved in any test failures when
running tests with '-x' and /bin/sh.
The other test helper functions are left unchanged, because they
either don't run commands specified as their arguments, or redirecting
their stderr wouldn't make sense, or both.
With this change the number of failures when running the test suite
with '-x' tracing and /bin/sh goes down from 340 failed tests in 43
test scripts to 22 failed tests in 6 scripts (or 23 in 7, if the
system (OSX) uses an older Bash version without BASH_XTRACEFD to run
't9903-bash-prompt.sh').
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-25 13:40:15 +00:00
|
|
|
"$@" 2>&7
|
2012-02-17 10:25:08 +00:00
|
|
|
exit_code=$?
|
2015-11-27 09:15:13 +00:00
|
|
|
if test $exit_code -eq 0 && ! list_contains "$_test_ok" success
|
|
|
|
then
|
2018-02-22 06:48:37 +00:00
|
|
|
echo >&4 "test_must_fail: command succeeded: $*"
|
2012-02-17 10:25:08 +00:00
|
|
|
return 1
|
2016-06-24 19:45:04 +00:00
|
|
|
elif test_match_signal 13 $exit_code && list_contains "$_test_ok" sigpipe
|
2015-11-27 09:15:14 +00:00
|
|
|
then
|
|
|
|
return 0
|
2015-11-27 09:15:13 +00:00
|
|
|
elif test $exit_code -gt 129 && test $exit_code -le 192
|
|
|
|
then
|
2018-02-22 06:48:37 +00:00
|
|
|
echo >&4 "test_must_fail: died by signal $(($exit_code - 128)): $*"
|
2012-02-17 10:25:08 +00:00
|
|
|
return 1
|
2015-11-27 09:15:13 +00:00
|
|
|
elif test $exit_code -eq 127
|
|
|
|
then
|
2018-02-22 06:48:37 +00:00
|
|
|
echo >&4 "test_must_fail: command not found: $*"
|
2012-02-17 10:25:08 +00:00
|
|
|
return 1
|
2015-11-27 09:15:13 +00:00
|
|
|
elif test $exit_code -eq 126
|
|
|
|
then
|
2018-02-22 06:48:37 +00:00
|
|
|
echo >&4 "test_must_fail: valgrind error: $*"
|
2013-03-31 08:37:25 +00:00
|
|
|
return 1
|
2012-02-17 10:25:08 +00:00
|
|
|
fi
|
|
|
|
return 0
|
t: prevent '-x' tracing from interfering with test helpers' stderr
Running a test script with '-x' turns on 'set -x' tracing, the output
of which is normally sent to stderr. This causes a lot of
test failures, because many tests redirect and verify the stderr
of shell functions, most frequently that of 'test_must_fail'.
These issues were worked around somewhat in d88785e424 (test-lib: set
BASH_XTRACEFD automatically, 2016-05-11), so at least we could
reliably run tests with '-x' tracing under a Bash version supporting
BASH_XTRACEFD, i.e. v4.1 and later.
Futhermore, redirecting the stderr of test helper functions like
'test_must_fail' or 'test_expect_code' is the cause of a different
issue as well. If these functions detect something unexpected, they
will write their error messages intended to the user to thier stderr.
However, if their stderr is redirected in order to save and verify the
stderr of the tested git command invoked in the function, then the
function's error messages will be redirected as well. Consequently,
those messages won't reach the user, making the test's verbose output
less useful.
This patch makes it safe to redirect and verify the stderr of those
test helper functions which are meant to run the tested command given
as argument, even when running tests with '-x' and /bin/sh. This is
achieved through a couple of file descriptor redirections:
- Duplicate stderr of the tested command executed in the test helper
function from the function's fd 7 (see next point), to ensure that
the tested command's error messages go to a different fd than the
'-x' trace of the commands executed in the function or the
function's error messages.
- Duplicate the test helper function's fd 7 from the function's
original stderr, meaning that, after taking a detour through fd 7,
the error messages of the tested command do end up on the
function's original stderr.
- Duplicate stderr of the test helper function from fd 4, i.e. the
fd connected to the test script's original stderr and the fd used
for BASH_XTRACEFD. This ensures that the '-x' trace of the
commands executed in the function
- doesn't go to the function's original stderr, so it won't mess
with callers who want to save and verify the tested command's
stderr.
- does go to the same fd independently from the shell running
the test script, be it /bin/sh, an older Bash without
BASH_XTRACEFD, or a more recent Bash already supporting
BASH_XTRACEFD.
Furthermore, this also makes sure that the function's error
messages go to this fd 4, meaning that the user will be able to
see them even if the function's stderr is redirected in the test.
- Specify the latter two redirections above in the test helper
function's definition, so they are performed every time the
function is invoked, without the need to modify the callsites of
the function.
Perform these redirections in those test helper functions which can be
expected to have their stderr redirected, i.e. in the functions
'test_must_fail', 'test_might_fail', 'test_expect_code', 'test_env',
'nongit', 'test_terminal' and 'perl'. Note that 'test_might_fail',
'test_env', and 'nongit' are not involved in any test failures when
running tests with '-x' and /bin/sh.
The other test helper functions are left unchanged, because they
either don't run commands specified as their arguments, or redirecting
their stderr wouldn't make sense, or both.
With this change the number of failures when running the test suite
with '-x' tracing and /bin/sh goes down from 340 failed tests in 43
test scripts to 22 failed tests in 6 scripts (or 23 in 7, if the
system (OSX) uses an older Bash version without BASH_XTRACEFD to run
't9903-bash-prompt.sh').
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-25 13:40:15 +00:00
|
|
|
} 7>&2 2>&4
|
2012-02-17 10:25:08 +00:00
|
|
|
|
|
|
|
# Similar to test_must_fail, but tolerates success, too. This is
|
|
|
|
# meant to be used in contexts like:
|
|
|
|
#
|
|
|
|
# test_expect_success 'some command works without configuration' '
|
|
|
|
# test_might_fail git config --unset all.configuration &&
|
|
|
|
# do something
|
|
|
|
# '
|
|
|
|
#
|
|
|
|
# Writing "git config --unset all.configuration || :" would be wrong,
|
|
|
|
# because we want to notice if it fails due to segv.
|
2018-02-09 02:42:33 +00:00
|
|
|
#
|
|
|
|
# Accepts the same options as test_must_fail.
|
2012-02-17 10:25:08 +00:00
|
|
|
|
|
|
|
test_might_fail () {
|
t: prevent '-x' tracing from interfering with test helpers' stderr
Running a test script with '-x' turns on 'set -x' tracing, the output
of which is normally sent to stderr. This causes a lot of
test failures, because many tests redirect and verify the stderr
of shell functions, most frequently that of 'test_must_fail'.
These issues were worked around somewhat in d88785e424 (test-lib: set
BASH_XTRACEFD automatically, 2016-05-11), so at least we could
reliably run tests with '-x' tracing under a Bash version supporting
BASH_XTRACEFD, i.e. v4.1 and later.
Futhermore, redirecting the stderr of test helper functions like
'test_must_fail' or 'test_expect_code' is the cause of a different
issue as well. If these functions detect something unexpected, they
will write their error messages intended to the user to thier stderr.
However, if their stderr is redirected in order to save and verify the
stderr of the tested git command invoked in the function, then the
function's error messages will be redirected as well. Consequently,
those messages won't reach the user, making the test's verbose output
less useful.
This patch makes it safe to redirect and verify the stderr of those
test helper functions which are meant to run the tested command given
as argument, even when running tests with '-x' and /bin/sh. This is
achieved through a couple of file descriptor redirections:
- Duplicate stderr of the tested command executed in the test helper
function from the function's fd 7 (see next point), to ensure that
the tested command's error messages go to a different fd than the
'-x' trace of the commands executed in the function or the
function's error messages.
- Duplicate the test helper function's fd 7 from the function's
original stderr, meaning that, after taking a detour through fd 7,
the error messages of the tested command do end up on the
function's original stderr.
- Duplicate stderr of the test helper function from fd 4, i.e. the
fd connected to the test script's original stderr and the fd used
for BASH_XTRACEFD. This ensures that the '-x' trace of the
commands executed in the function
- doesn't go to the function's original stderr, so it won't mess
with callers who want to save and verify the tested command's
stderr.
- does go to the same fd independently from the shell running
the test script, be it /bin/sh, an older Bash without
BASH_XTRACEFD, or a more recent Bash already supporting
BASH_XTRACEFD.
Furthermore, this also makes sure that the function's error
messages go to this fd 4, meaning that the user will be able to
see them even if the function's stderr is redirected in the test.
- Specify the latter two redirections above in the test helper
function's definition, so they are performed every time the
function is invoked, without the need to modify the callsites of
the function.
Perform these redirections in those test helper functions which can be
expected to have their stderr redirected, i.e. in the functions
'test_must_fail', 'test_might_fail', 'test_expect_code', 'test_env',
'nongit', 'test_terminal' and 'perl'. Note that 'test_might_fail',
'test_env', and 'nongit' are not involved in any test failures when
running tests with '-x' and /bin/sh.
The other test helper functions are left unchanged, because they
either don't run commands specified as their arguments, or redirecting
their stderr wouldn't make sense, or both.
With this change the number of failures when running the test suite
with '-x' tracing and /bin/sh goes down from 340 failed tests in 43
test scripts to 22 failed tests in 6 scripts (or 23 in 7, if the
system (OSX) uses an older Bash version without BASH_XTRACEFD to run
't9903-bash-prompt.sh').
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-25 13:40:15 +00:00
|
|
|
test_must_fail ok=success "$@" 2>&7
|
|
|
|
} 7>&2 2>&4
|
2012-02-17 10:25:08 +00:00
|
|
|
|
|
|
|
# Similar to test_must_fail and test_might_fail, but check that a
|
|
|
|
# given command exited with a given exit code. Meant to be used as:
|
|
|
|
#
|
|
|
|
# test_expect_success 'Merge with d/f conflicts' '
|
|
|
|
# test_expect_code 1 git merge "merge msg" B master
|
|
|
|
# '
|
|
|
|
|
|
|
|
test_expect_code () {
|
|
|
|
want_code=$1
|
|
|
|
shift
|
t: prevent '-x' tracing from interfering with test helpers' stderr
Running a test script with '-x' turns on 'set -x' tracing, the output
of which is normally sent to stderr. This causes a lot of
test failures, because many tests redirect and verify the stderr
of shell functions, most frequently that of 'test_must_fail'.
These issues were worked around somewhat in d88785e424 (test-lib: set
BASH_XTRACEFD automatically, 2016-05-11), so at least we could
reliably run tests with '-x' tracing under a Bash version supporting
BASH_XTRACEFD, i.e. v4.1 and later.
Futhermore, redirecting the stderr of test helper functions like
'test_must_fail' or 'test_expect_code' is the cause of a different
issue as well. If these functions detect something unexpected, they
will write their error messages intended to the user to thier stderr.
However, if their stderr is redirected in order to save and verify the
stderr of the tested git command invoked in the function, then the
function's error messages will be redirected as well. Consequently,
those messages won't reach the user, making the test's verbose output
less useful.
This patch makes it safe to redirect and verify the stderr of those
test helper functions which are meant to run the tested command given
as argument, even when running tests with '-x' and /bin/sh. This is
achieved through a couple of file descriptor redirections:
- Duplicate stderr of the tested command executed in the test helper
function from the function's fd 7 (see next point), to ensure that
the tested command's error messages go to a different fd than the
'-x' trace of the commands executed in the function or the
function's error messages.
- Duplicate the test helper function's fd 7 from the function's
original stderr, meaning that, after taking a detour through fd 7,
the error messages of the tested command do end up on the
function's original stderr.
- Duplicate stderr of the test helper function from fd 4, i.e. the
fd connected to the test script's original stderr and the fd used
for BASH_XTRACEFD. This ensures that the '-x' trace of the
commands executed in the function
- doesn't go to the function's original stderr, so it won't mess
with callers who want to save and verify the tested command's
stderr.
- does go to the same fd independently from the shell running
the test script, be it /bin/sh, an older Bash without
BASH_XTRACEFD, or a more recent Bash already supporting
BASH_XTRACEFD.
Furthermore, this also makes sure that the function's error
messages go to this fd 4, meaning that the user will be able to
see them even if the function's stderr is redirected in the test.
- Specify the latter two redirections above in the test helper
function's definition, so they are performed every time the
function is invoked, without the need to modify the callsites of
the function.
Perform these redirections in those test helper functions which can be
expected to have their stderr redirected, i.e. in the functions
'test_must_fail', 'test_might_fail', 'test_expect_code', 'test_env',
'nongit', 'test_terminal' and 'perl'. Note that 'test_might_fail',
'test_env', and 'nongit' are not involved in any test failures when
running tests with '-x' and /bin/sh.
The other test helper functions are left unchanged, because they
either don't run commands specified as their arguments, or redirecting
their stderr wouldn't make sense, or both.
With this change the number of failures when running the test suite
with '-x' tracing and /bin/sh goes down from 340 failed tests in 43
test scripts to 22 failed tests in 6 scripts (or 23 in 7, if the
system (OSX) uses an older Bash version without BASH_XTRACEFD to run
't9903-bash-prompt.sh').
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-25 13:40:15 +00:00
|
|
|
"$@" 2>&7
|
2012-02-17 10:25:08 +00:00
|
|
|
exit_code=$?
|
|
|
|
if test $exit_code = $want_code
|
|
|
|
then
|
|
|
|
return 0
|
|
|
|
fi
|
|
|
|
|
2018-02-22 06:48:37 +00:00
|
|
|
echo >&4 "test_expect_code: command exited with $exit_code, we wanted $want_code $*"
|
2012-02-17 10:25:08 +00:00
|
|
|
return 1
|
t: prevent '-x' tracing from interfering with test helpers' stderr
Running a test script with '-x' turns on 'set -x' tracing, the output
of which is normally sent to stderr. This causes a lot of
test failures, because many tests redirect and verify the stderr
of shell functions, most frequently that of 'test_must_fail'.
These issues were worked around somewhat in d88785e424 (test-lib: set
BASH_XTRACEFD automatically, 2016-05-11), so at least we could
reliably run tests with '-x' tracing under a Bash version supporting
BASH_XTRACEFD, i.e. v4.1 and later.
Futhermore, redirecting the stderr of test helper functions like
'test_must_fail' or 'test_expect_code' is the cause of a different
issue as well. If these functions detect something unexpected, they
will write their error messages intended to the user to thier stderr.
However, if their stderr is redirected in order to save and verify the
stderr of the tested git command invoked in the function, then the
function's error messages will be redirected as well. Consequently,
those messages won't reach the user, making the test's verbose output
less useful.
This patch makes it safe to redirect and verify the stderr of those
test helper functions which are meant to run the tested command given
as argument, even when running tests with '-x' and /bin/sh. This is
achieved through a couple of file descriptor redirections:
- Duplicate stderr of the tested command executed in the test helper
function from the function's fd 7 (see next point), to ensure that
the tested command's error messages go to a different fd than the
'-x' trace of the commands executed in the function or the
function's error messages.
- Duplicate the test helper function's fd 7 from the function's
original stderr, meaning that, after taking a detour through fd 7,
the error messages of the tested command do end up on the
function's original stderr.
- Duplicate stderr of the test helper function from fd 4, i.e. the
fd connected to the test script's original stderr and the fd used
for BASH_XTRACEFD. This ensures that the '-x' trace of the
commands executed in the function
- doesn't go to the function's original stderr, so it won't mess
with callers who want to save and verify the tested command's
stderr.
- does go to the same fd independently from the shell running
the test script, be it /bin/sh, an older Bash without
BASH_XTRACEFD, or a more recent Bash already supporting
BASH_XTRACEFD.
Furthermore, this also makes sure that the function's error
messages go to this fd 4, meaning that the user will be able to
see them even if the function's stderr is redirected in the test.
- Specify the latter two redirections above in the test helper
function's definition, so they are performed every time the
function is invoked, without the need to modify the callsites of
the function.
Perform these redirections in those test helper functions which can be
expected to have their stderr redirected, i.e. in the functions
'test_must_fail', 'test_might_fail', 'test_expect_code', 'test_env',
'nongit', 'test_terminal' and 'perl'. Note that 'test_might_fail',
'test_env', and 'nongit' are not involved in any test failures when
running tests with '-x' and /bin/sh.
The other test helper functions are left unchanged, because they
either don't run commands specified as their arguments, or redirecting
their stderr wouldn't make sense, or both.
With this change the number of failures when running the test suite
with '-x' tracing and /bin/sh goes down from 340 failed tests in 43
test scripts to 22 failed tests in 6 scripts (or 23 in 7, if the
system (OSX) uses an older Bash version without BASH_XTRACEFD to run
't9903-bash-prompt.sh').
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-25 13:40:15 +00:00
|
|
|
} 7>&2 2>&4
|
2012-02-17 10:25:08 +00:00
|
|
|
|
|
|
|
# test_cmp is a helper function to compare actual and expected output.
|
|
|
|
# You can use it like:
|
|
|
|
#
|
|
|
|
# test_expect_success 'foo works' '
|
|
|
|
# echo expected >expected &&
|
|
|
|
# foo >actual &&
|
|
|
|
# test_cmp expected actual
|
|
|
|
# '
|
|
|
|
#
|
|
|
|
# This could be written as either "cmp" or "diff -u", but:
|
|
|
|
# - cmp's output is not nearly as easy to read as diff -u
|
|
|
|
# - not all diff versions understand "-u"
|
|
|
|
|
2020-12-01 00:46:49 +00:00
|
|
|
test_cmp () {
|
2021-02-12 13:29:42 +00:00
|
|
|
test "$#" -ne 2 && BUG "2 param"
|
2020-10-16 20:51:04 +00:00
|
|
|
eval "$GIT_TEST_CMP" '"$@"'
|
2012-02-17 10:25:08 +00:00
|
|
|
}
|
|
|
|
|
2018-10-21 14:02:27 +00:00
|
|
|
# Check that the given config key has the expected value.
|
|
|
|
#
|
|
|
|
# test_cmp_config [-C <dir>] <expected-value>
|
|
|
|
# [<git-config-options>...] <config-key>
|
|
|
|
#
|
|
|
|
# for example to check that the value of core.bar is foo
|
|
|
|
#
|
|
|
|
# test_cmp_config foo core.bar
|
|
|
|
#
|
2020-12-01 00:46:49 +00:00
|
|
|
test_cmp_config () {
|
2018-10-21 14:02:27 +00:00
|
|
|
local GD &&
|
|
|
|
if test "$1" = "-C"
|
|
|
|
then
|
|
|
|
shift &&
|
|
|
|
GD="-C $1" &&
|
|
|
|
shift
|
|
|
|
fi &&
|
|
|
|
printf "%s\n" "$1" >expect.config &&
|
|
|
|
shift &&
|
|
|
|
git $GD config "$@" >actual.config &&
|
|
|
|
test_cmp expect.config actual.config
|
|
|
|
}
|
|
|
|
|
2014-06-04 15:57:52 +00:00
|
|
|
# test_cmp_bin - helper to compare binary files
|
|
|
|
|
2020-12-01 00:46:49 +00:00
|
|
|
test_cmp_bin () {
|
2021-02-12 13:29:42 +00:00
|
|
|
test "$#" -ne 2 && BUG "2 param"
|
2020-10-16 20:51:04 +00:00
|
|
|
cmp "$@"
|
2014-06-04 15:57:52 +00:00
|
|
|
}
|
|
|
|
|
2018-02-08 15:56:54 +00:00
|
|
|
test_i18ngrep () {
|
2024-03-02 17:13:51 +00:00
|
|
|
BUG "do not use test_i18ngrep---use test_grep instead"
|
2023-10-31 05:23:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
test_grep () {
|
t: validate 'test_i18ngrep's parameters
Some of the previous patches in this series fixed bogus
'test_i18ngrep' invocations:
- Two invocations where the tested git command's standard output is
directly piped into 'test_i18ngrep'. While convenient, this is an
antipattern, because the pipe hides the git command's exit code,
and the test could continue even if the command exited with error.
- Two invocations that had neither a filename parameter nor anything
piped into their standard input, yet both managed to remain
unnoticed for years. A third similarly bogus invocation is
currently lurking in 'pu' for a couple of weeks now.
Prevent similar mistakes in the future by validating 'test_i18ngrep's
parameters requiring that
- The last parameter names an existing file to be read, effectively
forbidding piping into 'test_i18ngrep'.
Note that this change will also forbid cases where 'test_i18ngrep'
would legitimately read its standard input, e.g. when its standard
input is redirected from a file, or when a git command's standard
output is first written to an intermediate file, which is then
preprocessed by a non-git command before the results are piped
into 'test_i18ngrep'. See two of the previous patches for the
only such cases we had in our test suite. However, reliably
preventing the piping antipattern is arguably more important than
supporting these cases, which can be easily worked around by
opening the file directly or using an intermediate file anyway.
- There are at least two parameters, not including the optional '!'
to negate the pattern. This ought to catch corner cases when
'test_i18ngrep' looks for the name of an existing file on its
standard input; the above check would miss this case becase the
filename as pattern would be the last parameter.
Note that this is not quite perfect, as it doesn't account for any
'grep --options' given as parameters. However, doing so would be
far too complicated, considering that patterns can start with
dashes as well, and in the majority of the cases we don't use any
such options anyway.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-08 15:56:55 +00:00
|
|
|
eval "last_arg=\${$#}"
|
|
|
|
|
|
|
|
test -f "$last_arg" ||
|
2023-10-31 05:23:29 +00:00
|
|
|
BUG "test_grep requires a file to read as the last parameter"
|
t: validate 'test_i18ngrep's parameters
Some of the previous patches in this series fixed bogus
'test_i18ngrep' invocations:
- Two invocations where the tested git command's standard output is
directly piped into 'test_i18ngrep'. While convenient, this is an
antipattern, because the pipe hides the git command's exit code,
and the test could continue even if the command exited with error.
- Two invocations that had neither a filename parameter nor anything
piped into their standard input, yet both managed to remain
unnoticed for years. A third similarly bogus invocation is
currently lurking in 'pu' for a couple of weeks now.
Prevent similar mistakes in the future by validating 'test_i18ngrep's
parameters requiring that
- The last parameter names an existing file to be read, effectively
forbidding piping into 'test_i18ngrep'.
Note that this change will also forbid cases where 'test_i18ngrep'
would legitimately read its standard input, e.g. when its standard
input is redirected from a file, or when a git command's standard
output is first written to an intermediate file, which is then
preprocessed by a non-git command before the results are piped
into 'test_i18ngrep'. See two of the previous patches for the
only such cases we had in our test suite. However, reliably
preventing the piping antipattern is arguably more important than
supporting these cases, which can be easily worked around by
opening the file directly or using an intermediate file anyway.
- There are at least two parameters, not including the optional '!'
to negate the pattern. This ought to catch corner cases when
'test_i18ngrep' looks for the name of an existing file on its
standard input; the above check would miss this case becase the
filename as pattern would be the last parameter.
Note that this is not quite perfect, as it doesn't account for any
'grep --options' given as parameters. However, doing so would be
far too complicated, considering that patterns can start with
dashes as well, and in the majority of the cases we don't use any
such options anyway.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-08 15:56:55 +00:00
|
|
|
|
|
|
|
if test $# -lt 2 ||
|
|
|
|
{ test "x!" = "x$1" && test $# -lt 3 ; }
|
|
|
|
then
|
2023-12-03 17:17:59 +00:00
|
|
|
BUG "too few parameters to test_grep"
|
t: validate 'test_i18ngrep's parameters
Some of the previous patches in this series fixed bogus
'test_i18ngrep' invocations:
- Two invocations where the tested git command's standard output is
directly piped into 'test_i18ngrep'. While convenient, this is an
antipattern, because the pipe hides the git command's exit code,
and the test could continue even if the command exited with error.
- Two invocations that had neither a filename parameter nor anything
piped into their standard input, yet both managed to remain
unnoticed for years. A third similarly bogus invocation is
currently lurking in 'pu' for a couple of weeks now.
Prevent similar mistakes in the future by validating 'test_i18ngrep's
parameters requiring that
- The last parameter names an existing file to be read, effectively
forbidding piping into 'test_i18ngrep'.
Note that this change will also forbid cases where 'test_i18ngrep'
would legitimately read its standard input, e.g. when its standard
input is redirected from a file, or when a git command's standard
output is first written to an intermediate file, which is then
preprocessed by a non-git command before the results are piped
into 'test_i18ngrep'. See two of the previous patches for the
only such cases we had in our test suite. However, reliably
preventing the piping antipattern is arguably more important than
supporting these cases, which can be easily worked around by
opening the file directly or using an intermediate file anyway.
- There are at least two parameters, not including the optional '!'
to negate the pattern. This ought to catch corner cases when
'test_i18ngrep' looks for the name of an existing file on its
standard input; the above check would miss this case becase the
filename as pattern would be the last parameter.
Note that this is not quite perfect, as it doesn't account for any
'grep --options' given as parameters. However, doing so would be
far too complicated, considering that patterns can start with
dashes as well, and in the majority of the cases we don't use any
such options anyway.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-08 15:56:55 +00:00
|
|
|
fi
|
|
|
|
|
t: make 'test_i18ngrep' more informative on failure
When 'test_i18ngrep' can't find the expected pattern, it exits
completely silently; when its negated form does find the pattern that
shouldn't be there, it prints the matching line(s) but otherwise exits
without any error message. This leaves the developer puzzled about
what could have gone wrong.
Make 'test_i18ngrep' more informative on failure by printing an error
message including the invoked 'grep' command and the contents of the
file it had to scan through.
Note that this "dump the scanned file" part is not quite perfect, as
it dumps only the file specified as the function's last positional
parameter, thus assuming that there is only a single file parameter.
I think that's a reasonable assumption to make, one that holds true in
the current code base. And even if someone were to scan multiple
files at once in the future, the worst thing that could happen is that
the verbose error message won't include the contents of all those
files, only the last one. Alas, we can't really do any better than
this, because checking whether the other positional parameters match a
filename can result in false positives: 't3400-rebase.sh' and
't3404-rebase-interactive.sh' contain one test each, where the
'test_i18ngrep's pattern verbatimly matches a file in the trash
directory.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-08 15:56:56 +00:00
|
|
|
if test "x!" = "x$1"
|
2018-02-08 15:56:54 +00:00
|
|
|
then
|
|
|
|
shift
|
t: make 'test_i18ngrep' more informative on failure
When 'test_i18ngrep' can't find the expected pattern, it exits
completely silently; when its negated form does find the pattern that
shouldn't be there, it prints the matching line(s) but otherwise exits
without any error message. This leaves the developer puzzled about
what could have gone wrong.
Make 'test_i18ngrep' more informative on failure by printing an error
message including the invoked 'grep' command and the contents of the
file it had to scan through.
Note that this "dump the scanned file" part is not quite perfect, as
it dumps only the file specified as the function's last positional
parameter, thus assuming that there is only a single file parameter.
I think that's a reasonable assumption to make, one that holds true in
the current code base. And even if someone were to scan multiple
files at once in the future, the worst thing that could happen is that
the verbose error message won't include the contents of all those
files, only the last one. Alas, we can't really do any better than
this, because checking whether the other positional parameters match a
filename can result in false positives: 't3400-rebase.sh' and
't3404-rebase-interactive.sh' contain one test each, where the
'test_i18ngrep's pattern verbatimly matches a file in the trash
directory.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-08 15:56:56 +00:00
|
|
|
! grep "$@" && return 0
|
|
|
|
|
2018-02-22 06:48:37 +00:00
|
|
|
echo >&4 "error: '! grep $@' did find a match in:"
|
2018-02-08 15:56:54 +00:00
|
|
|
else
|
t: make 'test_i18ngrep' more informative on failure
When 'test_i18ngrep' can't find the expected pattern, it exits
completely silently; when its negated form does find the pattern that
shouldn't be there, it prints the matching line(s) but otherwise exits
without any error message. This leaves the developer puzzled about
what could have gone wrong.
Make 'test_i18ngrep' more informative on failure by printing an error
message including the invoked 'grep' command and the contents of the
file it had to scan through.
Note that this "dump the scanned file" part is not quite perfect, as
it dumps only the file specified as the function's last positional
parameter, thus assuming that there is only a single file parameter.
I think that's a reasonable assumption to make, one that holds true in
the current code base. And even if someone were to scan multiple
files at once in the future, the worst thing that could happen is that
the verbose error message won't include the contents of all those
files, only the last one. Alas, we can't really do any better than
this, because checking whether the other positional parameters match a
filename can result in false positives: 't3400-rebase.sh' and
't3404-rebase-interactive.sh' contain one test each, where the
'test_i18ngrep's pattern verbatimly matches a file in the trash
directory.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-08 15:56:56 +00:00
|
|
|
grep "$@" && return 0
|
|
|
|
|
2018-02-22 06:48:37 +00:00
|
|
|
echo >&4 "error: 'grep $@' didn't find a match in:"
|
2018-02-08 15:56:54 +00:00
|
|
|
fi
|
t: make 'test_i18ngrep' more informative on failure
When 'test_i18ngrep' can't find the expected pattern, it exits
completely silently; when its negated form does find the pattern that
shouldn't be there, it prints the matching line(s) but otherwise exits
without any error message. This leaves the developer puzzled about
what could have gone wrong.
Make 'test_i18ngrep' more informative on failure by printing an error
message including the invoked 'grep' command and the contents of the
file it had to scan through.
Note that this "dump the scanned file" part is not quite perfect, as
it dumps only the file specified as the function's last positional
parameter, thus assuming that there is only a single file parameter.
I think that's a reasonable assumption to make, one that holds true in
the current code base. And even if someone were to scan multiple
files at once in the future, the worst thing that could happen is that
the verbose error message won't include the contents of all those
files, only the last one. Alas, we can't really do any better than
this, because checking whether the other positional parameters match a
filename can result in false positives: 't3400-rebase.sh' and
't3404-rebase-interactive.sh' contain one test each, where the
'test_i18ngrep's pattern verbatimly matches a file in the trash
directory.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-08 15:56:56 +00:00
|
|
|
|
|
|
|
if test -s "$last_arg"
|
|
|
|
then
|
2018-02-22 06:48:37 +00:00
|
|
|
cat >&4 "$last_arg"
|
t: make 'test_i18ngrep' more informative on failure
When 'test_i18ngrep' can't find the expected pattern, it exits
completely silently; when its negated form does find the pattern that
shouldn't be there, it prints the matching line(s) but otherwise exits
without any error message. This leaves the developer puzzled about
what could have gone wrong.
Make 'test_i18ngrep' more informative on failure by printing an error
message including the invoked 'grep' command and the contents of the
file it had to scan through.
Note that this "dump the scanned file" part is not quite perfect, as
it dumps only the file specified as the function's last positional
parameter, thus assuming that there is only a single file parameter.
I think that's a reasonable assumption to make, one that holds true in
the current code base. And even if someone were to scan multiple
files at once in the future, the worst thing that could happen is that
the verbose error message won't include the contents of all those
files, only the last one. Alas, we can't really do any better than
this, because checking whether the other positional parameters match a
filename can result in false positives: 't3400-rebase.sh' and
't3404-rebase-interactive.sh' contain one test each, where the
'test_i18ngrep's pattern verbatimly matches a file in the trash
directory.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-08 15:56:56 +00:00
|
|
|
else
|
2018-02-22 06:48:37 +00:00
|
|
|
echo >&4 "<File '$last_arg' is empty>"
|
t: make 'test_i18ngrep' more informative on failure
When 'test_i18ngrep' can't find the expected pattern, it exits
completely silently; when its negated form does find the pattern that
shouldn't be there, it prints the matching line(s) but otherwise exits
without any error message. This leaves the developer puzzled about
what could have gone wrong.
Make 'test_i18ngrep' more informative on failure by printing an error
message including the invoked 'grep' command and the contents of the
file it had to scan through.
Note that this "dump the scanned file" part is not quite perfect, as
it dumps only the file specified as the function's last positional
parameter, thus assuming that there is only a single file parameter.
I think that's a reasonable assumption to make, one that holds true in
the current code base. And even if someone were to scan multiple
files at once in the future, the worst thing that could happen is that
the verbose error message won't include the contents of all those
files, only the last one. Alas, we can't really do any better than
this, because checking whether the other positional parameters match a
filename can result in false positives: 't3400-rebase.sh' and
't3404-rebase-interactive.sh' contain one test each, where the
'test_i18ngrep's pattern verbatimly matches a file in the trash
directory.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-08 15:56:56 +00:00
|
|
|
fi
|
|
|
|
|
|
|
|
return 1
|
2018-02-08 15:56:54 +00:00
|
|
|
}
|
|
|
|
|
2013-06-09 18:29:20 +00:00
|
|
|
# Check if the file expected to be empty is indeed empty, and barfs
|
|
|
|
# otherwise.
|
|
|
|
|
|
|
|
test_must_be_empty () {
|
2021-02-12 13:29:42 +00:00
|
|
|
test "$#" -ne 1 && BUG "1 param"
|
2018-03-26 13:11:24 +00:00
|
|
|
test_path_is_file "$1" &&
|
|
|
|
if test -s "$1"
|
2013-06-09 18:29:20 +00:00
|
|
|
then
|
|
|
|
echo "'$1' is not empty, it contains:"
|
|
|
|
cat "$1"
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
2019-11-12 23:07:45 +00:00
|
|
|
# Tests that its two parameters refer to the same revision, or if '!' is
|
|
|
|
# provided first, that its other two parameters refer to different
|
|
|
|
# revisions.
|
2012-12-21 19:10:10 +00:00
|
|
|
test_cmp_rev () {
|
2019-11-12 23:07:45 +00:00
|
|
|
local op='=' wrong_result=different
|
|
|
|
|
|
|
|
if test $# -ge 1 && test "x$1" = 'x!'
|
|
|
|
then
|
|
|
|
op='!='
|
|
|
|
wrong_result='the same'
|
|
|
|
shift
|
|
|
|
fi
|
2018-11-19 13:28:18 +00:00
|
|
|
if test $# != 2
|
|
|
|
then
|
2021-02-09 21:41:49 +00:00
|
|
|
BUG "test_cmp_rev requires two revisions, but got $#"
|
2018-11-19 13:28:18 +00:00
|
|
|
else
|
|
|
|
local r1 r2
|
|
|
|
r1=$(git rev-parse --verify "$1") &&
|
2019-11-12 23:07:45 +00:00
|
|
|
r2=$(git rev-parse --verify "$2") || return 1
|
|
|
|
|
|
|
|
if ! test "$r1" "$op" "$r2"
|
2018-11-19 13:28:18 +00:00
|
|
|
then
|
|
|
|
cat >&4 <<-EOF
|
2019-11-12 23:07:45 +00:00
|
|
|
error: two revisions point to $wrong_result objects:
|
2018-11-19 13:28:18 +00:00
|
|
|
'$1': $r1
|
|
|
|
'$2': $r2
|
|
|
|
EOF
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
fi
|
2012-12-21 19:10:10 +00:00
|
|
|
}
|
|
|
|
|
2023-08-03 13:09:35 +00:00
|
|
|
# Tests that a commit message matches the expected text
|
|
|
|
#
|
|
|
|
# Usage: test_commit_message <rev> [-m <msg> | <file>]
|
|
|
|
#
|
|
|
|
# When using "-m" <msg> will have a line feed appended. If the second
|
|
|
|
# argument is omitted then the expected message is read from stdin.
|
|
|
|
|
|
|
|
test_commit_message () {
|
|
|
|
local msg_file=expect.msg
|
|
|
|
|
|
|
|
case $# in
|
|
|
|
3)
|
|
|
|
if test "$2" = "-m"
|
|
|
|
then
|
|
|
|
printf "%s\n" "$3" >"$msg_file"
|
|
|
|
else
|
|
|
|
BUG "Usage: test_commit_message <rev> [-m <message> | <file>]"
|
|
|
|
fi
|
|
|
|
;;
|
|
|
|
2)
|
|
|
|
msg_file="$2"
|
|
|
|
;;
|
|
|
|
1)
|
|
|
|
cat >"$msg_file"
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
BUG "Usage: test_commit_message <rev> [-m <message> | <file>]"
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
git show --no-patch --pretty=format:%B "$1" -- >actual.msg &&
|
|
|
|
test_cmp "$msg_file" actual.msg
|
|
|
|
}
|
|
|
|
|
t0001: fix on case-insensitive filesystems
On a case-insensitive filesystem, such as HFS+ or NTFS, it is possible
that the idea Bash has of the current directory differs in case from
what Git thinks it is. That's totally okay, though, and we should not
expect otherwise.
On Windows, for example, when you call
cd C:\GIT-SDK-64
in a PowerShell and there exists a directory called `C:\git-sdk-64`, the
current directory will be reported in all upper-case. Even in a Bash
that you might call from that PowerShell. Git, however, will have
normalized this via `GetFinalPathByHandle()`, and the expectation in
t0001 that the recorded gitdir will match what `pwd` says will be
violated.
Let's address this by comparing these paths in a case-insensitive
manner when `core.ignoreCase` is `true`.
Reported by Jameson Miller.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-24 17:40:05 +00:00
|
|
|
# Compare paths respecting core.ignoreCase
|
|
|
|
test_cmp_fspath () {
|
|
|
|
if test "x$1" = "x$2"
|
|
|
|
then
|
|
|
|
return 0
|
|
|
|
fi
|
|
|
|
|
|
|
|
if test true != "$(git config --get --type=bool core.ignorecase)"
|
|
|
|
then
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
test "x$(echo "$1" | tr A-Z a-z)" = "x$(echo "$2" | tr A-Z a-z)"
|
|
|
|
}
|
|
|
|
|
2016-05-09 18:36:09 +00:00
|
|
|
# Print a sequence of integers in increasing order, either with
|
|
|
|
# two arguments (start and end):
|
2012-08-03 22:21:04 +00:00
|
|
|
#
|
2016-05-09 18:36:09 +00:00
|
|
|
# test_seq 1 5 -- outputs 1 2 3 4 5 one line at a time
|
|
|
|
#
|
|
|
|
# or with one argument (end), in which case it starts counting
|
|
|
|
# from 1.
|
2012-08-03 22:21:04 +00:00
|
|
|
|
|
|
|
test_seq () {
|
|
|
|
case $# in
|
|
|
|
1) set 1 "$@" ;;
|
|
|
|
2) ;;
|
tests: send "bug in the test script" errors to the script's stderr
Some of the functions in our test library check that they were invoked
properly with conditions like this:
test "$#" = 2 ||
error "bug in the test script: not 2 parameters to test-expect-success"
If this particular condition is triggered, then 'error' will abort the
whole test script with a bold red error message [1] right away.
However, under certain circumstances the test script will be aborted
completely silently, namely if:
- a similar condition in a test helper function like
'test_line_count' is triggered,
- which is invoked from the test script's "main" shell [2],
- and the test script is run manually (i.e. './t1234-foo.sh' as
opposed to 'make t1234-foo.sh' or 'make test') [3]
- and without the '--verbose' option,
because the error message is printed from within 'test_eval_', where
standard output is redirected either to /dev/null or to a log file.
The only indication that something is wrong is that not all tests in
the script are executed and at the end of the test script's output
there is no "# passed all N tests" message, which are subtle and can
easily go unnoticed, as I had to experience myself.
Send these "bug in the test script" error messages directly to the
test scripts standard error and thus to the terminal, so those bugs
will be much harder to overlook. Instead of updating all ~20 such
'error' calls with a redirection, let's add a BUG() function to
'test-lib.sh', wrapping an 'error' call with the proper redirection
and also including the common prefix of those error messages, and
convert all those call sites [4] to use this new BUG() function
instead.
[1] That particular error message from 'test_expect_success' is
printed in color only when running with or without '--verbose';
with '--tee' or '--verbose-log' the error is printed without
color, but it is printed to the terminal nonetheless.
[2] If such a condition is triggered in a subshell of a test, then
'error' won't be able to abort the whole test script, but only the
subshell, which in turn causes the test to fail in the usual way,
indicating loudly and clearly that something is wrong.
[3] Well, 'error' aborts the test script the same way when run
manually or by 'make' or 'prove', but both 'make' and 'prove' pay
attention to the test script's exit status, and even a silently
aborted test script would then trigger those tools' usual
noticable error messages.
[4] Strictly speaking, not all those 'error' calls need that
redirection to send their output to the terminal, see e.g.
'test_expect_success' in the opening example, but I think it's
better to be consistent.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-19 13:13:26 +00:00
|
|
|
*) BUG "not 1 or 2 parameters to test_seq" ;;
|
2012-08-03 22:21:04 +00:00
|
|
|
esac
|
2016-05-09 19:37:01 +00:00
|
|
|
test_seq_counter__=$1
|
|
|
|
while test "$test_seq_counter__" -le "$2"
|
|
|
|
do
|
|
|
|
echo "$test_seq_counter__"
|
|
|
|
test_seq_counter__=$(( $test_seq_counter__ + 1 ))
|
|
|
|
done
|
2012-08-03 22:21:04 +00:00
|
|
|
}
|
|
|
|
|
2012-02-17 10:25:08 +00:00
|
|
|
# This function can be used to schedule some commands to be run
|
|
|
|
# unconditionally at the end of the test to restore sanity:
|
|
|
|
#
|
|
|
|
# test_expect_success 'test core.capslock' '
|
|
|
|
# git config core.capslock true &&
|
|
|
|
# test_when_finished "git config --unset core.capslock" &&
|
|
|
|
# hello world
|
|
|
|
# '
|
|
|
|
#
|
|
|
|
# That would be roughly equivalent to
|
|
|
|
#
|
|
|
|
# test_expect_success 'test core.capslock' '
|
|
|
|
# git config core.capslock true &&
|
|
|
|
# hello world
|
|
|
|
# git config --unset core.capslock
|
|
|
|
# '
|
|
|
|
#
|
|
|
|
# except that the greeting and config --unset must both succeed for
|
|
|
|
# the test to pass.
|
|
|
|
#
|
|
|
|
# Note that under --immediate mode, no clean-up is done to help diagnose
|
|
|
|
# what went wrong.
|
|
|
|
|
|
|
|
test_when_finished () {
|
2015-09-05 13:12:49 +00:00
|
|
|
# We cannot detect when we are in a subshell in general, but by
|
|
|
|
# doing so on Bash is better than nothing (the test will
|
|
|
|
# silently pass on other shells).
|
|
|
|
test "${BASH_SUBSHELL-0}" = 0 ||
|
tests: send "bug in the test script" errors to the script's stderr
Some of the functions in our test library check that they were invoked
properly with conditions like this:
test "$#" = 2 ||
error "bug in the test script: not 2 parameters to test-expect-success"
If this particular condition is triggered, then 'error' will abort the
whole test script with a bold red error message [1] right away.
However, under certain circumstances the test script will be aborted
completely silently, namely if:
- a similar condition in a test helper function like
'test_line_count' is triggered,
- which is invoked from the test script's "main" shell [2],
- and the test script is run manually (i.e. './t1234-foo.sh' as
opposed to 'make t1234-foo.sh' or 'make test') [3]
- and without the '--verbose' option,
because the error message is printed from within 'test_eval_', where
standard output is redirected either to /dev/null or to a log file.
The only indication that something is wrong is that not all tests in
the script are executed and at the end of the test script's output
there is no "# passed all N tests" message, which are subtle and can
easily go unnoticed, as I had to experience myself.
Send these "bug in the test script" error messages directly to the
test scripts standard error and thus to the terminal, so those bugs
will be much harder to overlook. Instead of updating all ~20 such
'error' calls with a redirection, let's add a BUG() function to
'test-lib.sh', wrapping an 'error' call with the proper redirection
and also including the common prefix of those error messages, and
convert all those call sites [4] to use this new BUG() function
instead.
[1] That particular error message from 'test_expect_success' is
printed in color only when running with or without '--verbose';
with '--tee' or '--verbose-log' the error is printed without
color, but it is printed to the terminal nonetheless.
[2] If such a condition is triggered in a subshell of a test, then
'error' won't be able to abort the whole test script, but only the
subshell, which in turn causes the test to fail in the usual way,
indicating loudly and clearly that something is wrong.
[3] Well, 'error' aborts the test script the same way when run
manually or by 'make' or 'prove', but both 'make' and 'prove' pay
attention to the test script's exit status, and even a silently
aborted test script would then trigger those tools' usual
noticable error messages.
[4] Strictly speaking, not all those 'error' calls need that
redirection to send their output to the terminal, see e.g.
'test_expect_success' in the opening example, but I think it's
better to be consistent.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-19 13:13:26 +00:00
|
|
|
BUG "test_when_finished does nothing in a subshell"
|
2012-02-17 10:25:08 +00:00
|
|
|
test_cleanup="{ $*
|
|
|
|
} && (exit \"\$eval_ret\"); eval_ret=\$?; $test_cleanup"
|
|
|
|
}
|
|
|
|
|
test-lib: introduce 'test_atexit'
When running Apache, 'git daemon', or p4d, we want to kill them at the
end of the test script, otherwise a leftover daemon process will keep
its port open indefinitely, and thus will interfere with subsequent
executions of the same test script.
So far, we stop these daemon processes "manually", i.e.:
- by registering functions or commands in the trap on EXIT to stop
the daemon while preserving the last seen exit code before the
trap (to deal with a failure when run with '--immediate' or with
interrupts by ctrl-C),
- and by invoking these functions/commands last thing before
'test_done' (and sometimes restoring the test framework's default
trap on EXIT, to prevent the daemons from being killed twice).
On one hand, we do this inconsistently, e.g. 'git p4' tests invoke
different functions in the trap on EXIT and in the last test before
'test_done', and they neither restore the test framework's default trap
on EXIT nor preserve the last seen exit code. On the other hand, this
is error prone, because, as shown in a previous patch in this series,
any output from the cleanup commands in the trap on EXIT can prevent a
proper cleanup when a test script run with '--verbose-log' and certain
shells, notably 'dash', is interrupted.
Let's introduce 'test_atexit', which is loosely modeled after
'test_when_finished', but has a broader scope: rather than running the
commands after the current test case, run them when the test script
finishes, and also run them when the test is interrupted, or exits
early in case of a failure while the '--immediate' option is in
effect.
When running the cleanup commands at the end of a successful test,
then they will be run in 'test_done' before it removes the trash
directory, i.e. the cleanup commands will still be able to access any
pidfiles or socket files in there. When running the cleanup commands
after an interrupt or failure with '--immediate', then they will be
run in the trap on EXIT. In both cases they will be run in
'test_eval_', i.e. both standard error and output of all cleanup
commands will go where they should according to the '-v' or
'--verbose-log' options, and thus won't cause any troubles when
interrupting a test script run with '--verbose-log'.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-13 12:24:11 +00:00
|
|
|
# This function can be used to schedule some commands to be run
|
|
|
|
# unconditionally at the end of the test script, e.g. to stop a daemon:
|
|
|
|
#
|
|
|
|
# test_expect_success 'test git daemon' '
|
|
|
|
# git daemon &
|
|
|
|
# daemon_pid=$! &&
|
|
|
|
# test_atexit 'kill $daemon_pid' &&
|
|
|
|
# hello world
|
|
|
|
# '
|
|
|
|
#
|
|
|
|
# The commands will be executed before the trash directory is removed,
|
|
|
|
# i.e. the atexit commands will still be able to access any pidfiles or
|
|
|
|
# socket files.
|
|
|
|
#
|
|
|
|
# Note that these commands will be run even when a test script run
|
|
|
|
# with '--immediate' fails. Be careful with your atexit commands to
|
|
|
|
# minimize any changes to the failed state.
|
|
|
|
|
|
|
|
test_atexit () {
|
|
|
|
# We cannot detect when we are in a subshell in general, but by
|
|
|
|
# doing so on Bash is better than nothing (the test will
|
|
|
|
# silently pass on other shells).
|
|
|
|
test "${BASH_SUBSHELL-0}" = 0 ||
|
2021-02-09 21:41:49 +00:00
|
|
|
BUG "test_atexit does nothing in a subshell"
|
test-lib: introduce 'test_atexit'
When running Apache, 'git daemon', or p4d, we want to kill them at the
end of the test script, otherwise a leftover daemon process will keep
its port open indefinitely, and thus will interfere with subsequent
executions of the same test script.
So far, we stop these daemon processes "manually", i.e.:
- by registering functions or commands in the trap on EXIT to stop
the daemon while preserving the last seen exit code before the
trap (to deal with a failure when run with '--immediate' or with
interrupts by ctrl-C),
- and by invoking these functions/commands last thing before
'test_done' (and sometimes restoring the test framework's default
trap on EXIT, to prevent the daemons from being killed twice).
On one hand, we do this inconsistently, e.g. 'git p4' tests invoke
different functions in the trap on EXIT and in the last test before
'test_done', and they neither restore the test framework's default trap
on EXIT nor preserve the last seen exit code. On the other hand, this
is error prone, because, as shown in a previous patch in this series,
any output from the cleanup commands in the trap on EXIT can prevent a
proper cleanup when a test script run with '--verbose-log' and certain
shells, notably 'dash', is interrupted.
Let's introduce 'test_atexit', which is loosely modeled after
'test_when_finished', but has a broader scope: rather than running the
commands after the current test case, run them when the test script
finishes, and also run them when the test is interrupted, or exits
early in case of a failure while the '--immediate' option is in
effect.
When running the cleanup commands at the end of a successful test,
then they will be run in 'test_done' before it removes the trash
directory, i.e. the cleanup commands will still be able to access any
pidfiles or socket files in there. When running the cleanup commands
after an interrupt or failure with '--immediate', then they will be
run in the trap on EXIT. In both cases they will be run in
'test_eval_', i.e. both standard error and output of all cleanup
commands will go where they should according to the '-v' or
'--verbose-log' options, and thus won't cause any troubles when
interrupting a test script run with '--verbose-log'.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-13 12:24:11 +00:00
|
|
|
test_atexit_cleanup="{ $*
|
|
|
|
} && (exit \"\$eval_ret\"); eval_ret=\$?; $test_atexit_cleanup"
|
|
|
|
}
|
|
|
|
|
test-lib: split up and deprecate test_create_repo()
Remove various redundant or obsolete code from the test_create_repo()
function, and split up its use in test-lib.sh from what tests need
from it.
This leave us with a pass-through wrapper for "git init" in
test-lib-functions.sh, in test-lib.sh we have the same, except for
needing to redirect stdout/stderr, and emitting an error ourselves if
it fails. We don't need to error() ourselves when test_create_repo()
is invoked, as the invocation will be a part of a test's "&&"-chain.
Everything below this paragraph is a detailed summary of the history
of test_create_repo() explaining why it's safe to remove the various
things it was doing:
1. "mkdir -p" isn't needed because "git init" itself will create
leading directories if needed.
2. Since we're now a simple wrapper for "git init" we don't need to
check that we have only one argument. If someone wants to run
"test_create_repo --bare x" that's OK.
3. We won't ever hit that "Cannot setup test environment"
error.
Checking the test environment sanity when doing "git init" dates
back to eea420693be (t0000: catch trivial pilot errors.,
2005-12-10) and 2ccd2027b01 (trivial: check, if t/trash directory
was successfully created, 2006-01-05).
We can also see it in another form a bit later in my own
0d314ce834d (test-lib: use subshell instead of cd $new && .. && cd
$old, 2010-08-30).
But since 2006f0adaee (t/test-lib: make sure Git has already been
built, 2012-09-17) we already check if we have a built git
earlier.
The one thing this was testing after that 2012 change was that
we'd just built "git", but not "git-init", but since
3af4c7156c4 (tests: respect GIT_TEST_INSTALLED when initializing
repositories, 2018-11-12) we invoke "git", not "git-init".
So all of that's been checked already, and we don't need to
re-check it here.
4. We don't need to move .git/hooks out of the way.
That dates back to c09a69a83e3 (Disable hooks during tests.,
2005-10-16), since then hooks became disabled by default in
f98f8cbac01 (Ship sample hooks with .sample suffix, 2008-06-24).
So the hooks were already disabled by default, but as can be seen
from "mkdir .git/hooks" changes various tests needed to re-setup
that directory. Now they no longer do.
This makes us implicitly depend on the default hooks being
disabled, which is a good thing. If and when we'd have any
on-by-default hooks (I see no reason we ever would) we'd want to
see the subtle and not so subtle ways that would break the test
suite.
5. We don't need to "cd" to the "$repo" directory at all anymore.
In the code being removed here we both "cd"'d to the repository
before calling "init", and did so in a subshell.
It's not important to do either, so both of those can be
removed. We cd'd because this code grew from test-lib.sh code
where we'd have done so already, see eedf8f97e58 (Abstract
test_create_repo out for use in tests., 2006-02-17), and later
"cd"'d inside a subshell since 0d314ce834d to avoid having to keep
track of an "old pwd" variable to cd back after the setup.
Being in the repository directory made moving the hooks around
easier (we wouldn't have to fully qualify the path). Since we're
not moving the hooks per #4 above we don't need to "cd" for that
reason either.
6. We can drop the --template argument and instead rely on the
GIT_TEMPLATE_DIR set to the same path earlier in test-lib.sh. See
8683a45d669 (Introduce GIT_TEMPLATE_DIR, 2006-12-19)
7. We only needed that ">&3 2>&4" redirection when invoked from
test-lib.sh.
We could still invoke test_create_repo() there, but as the
invocation is now trivial and we don't have a good reason to use
test_create_repo() elsewhere let's call "git init" there
ourselves.
8. We didn't need to resolve "git" as
"${GIT_TEST_INSTALLED:-$GIT_EXEC_PATH}/git$X" in test_create_repo(),
even for the use of test-lib.sh
PATH is already set up in test-lib.sh to start with
GIT_TEST_INSTALLED and/or GIT_EXEC_PATH before
test_create_repo() (now "git init") is called.. So we can simply
run "git" and rely on the PATH lookup choosing the right
executable.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-10 14:19:10 +00:00
|
|
|
# Deprecated wrapper for "git init", use "git init" directly instead
|
2012-02-17 10:25:08 +00:00
|
|
|
# Usage: test_create_repo <directory>
|
|
|
|
test_create_repo () {
|
test-lib: split up and deprecate test_create_repo()
Remove various redundant or obsolete code from the test_create_repo()
function, and split up its use in test-lib.sh from what tests need
from it.
This leave us with a pass-through wrapper for "git init" in
test-lib-functions.sh, in test-lib.sh we have the same, except for
needing to redirect stdout/stderr, and emitting an error ourselves if
it fails. We don't need to error() ourselves when test_create_repo()
is invoked, as the invocation will be a part of a test's "&&"-chain.
Everything below this paragraph is a detailed summary of the history
of test_create_repo() explaining why it's safe to remove the various
things it was doing:
1. "mkdir -p" isn't needed because "git init" itself will create
leading directories if needed.
2. Since we're now a simple wrapper for "git init" we don't need to
check that we have only one argument. If someone wants to run
"test_create_repo --bare x" that's OK.
3. We won't ever hit that "Cannot setup test environment"
error.
Checking the test environment sanity when doing "git init" dates
back to eea420693be (t0000: catch trivial pilot errors.,
2005-12-10) and 2ccd2027b01 (trivial: check, if t/trash directory
was successfully created, 2006-01-05).
We can also see it in another form a bit later in my own
0d314ce834d (test-lib: use subshell instead of cd $new && .. && cd
$old, 2010-08-30).
But since 2006f0adaee (t/test-lib: make sure Git has already been
built, 2012-09-17) we already check if we have a built git
earlier.
The one thing this was testing after that 2012 change was that
we'd just built "git", but not "git-init", but since
3af4c7156c4 (tests: respect GIT_TEST_INSTALLED when initializing
repositories, 2018-11-12) we invoke "git", not "git-init".
So all of that's been checked already, and we don't need to
re-check it here.
4. We don't need to move .git/hooks out of the way.
That dates back to c09a69a83e3 (Disable hooks during tests.,
2005-10-16), since then hooks became disabled by default in
f98f8cbac01 (Ship sample hooks with .sample suffix, 2008-06-24).
So the hooks were already disabled by default, but as can be seen
from "mkdir .git/hooks" changes various tests needed to re-setup
that directory. Now they no longer do.
This makes us implicitly depend on the default hooks being
disabled, which is a good thing. If and when we'd have any
on-by-default hooks (I see no reason we ever would) we'd want to
see the subtle and not so subtle ways that would break the test
suite.
5. We don't need to "cd" to the "$repo" directory at all anymore.
In the code being removed here we both "cd"'d to the repository
before calling "init", and did so in a subshell.
It's not important to do either, so both of those can be
removed. We cd'd because this code grew from test-lib.sh code
where we'd have done so already, see eedf8f97e58 (Abstract
test_create_repo out for use in tests., 2006-02-17), and later
"cd"'d inside a subshell since 0d314ce834d to avoid having to keep
track of an "old pwd" variable to cd back after the setup.
Being in the repository directory made moving the hooks around
easier (we wouldn't have to fully qualify the path). Since we're
not moving the hooks per #4 above we don't need to "cd" for that
reason either.
6. We can drop the --template argument and instead rely on the
GIT_TEMPLATE_DIR set to the same path earlier in test-lib.sh. See
8683a45d669 (Introduce GIT_TEMPLATE_DIR, 2006-12-19)
7. We only needed that ">&3 2>&4" redirection when invoked from
test-lib.sh.
We could still invoke test_create_repo() there, but as the
invocation is now trivial and we don't have a good reason to use
test_create_repo() elsewhere let's call "git init" there
ourselves.
8. We didn't need to resolve "git" as
"${GIT_TEST_INSTALLED:-$GIT_EXEC_PATH}/git$X" in test_create_repo(),
even for the use of test-lib.sh
PATH is already set up in test-lib.sh to start with
GIT_TEST_INSTALLED and/or GIT_EXEC_PATH before
test_create_repo() (now "git init") is called.. So we can simply
run "git" and rely on the PATH lookup choosing the right
executable.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-05-10 14:19:10 +00:00
|
|
|
git init "$@"
|
2012-02-17 10:25:08 +00:00
|
|
|
}
|
2013-06-07 20:53:27 +00:00
|
|
|
|
|
|
|
# This function helps on symlink challenged file systems when it is not
|
|
|
|
# important that the file system entry is a symbolic link.
|
|
|
|
# Use test_ln_s_add instead of "ln -s x y && git add y" to add a
|
|
|
|
# symbolic link entry y to the index.
|
|
|
|
|
|
|
|
test_ln_s_add () {
|
|
|
|
if test_have_prereq SYMLINKS
|
|
|
|
then
|
|
|
|
ln -s "$1" "$2" &&
|
|
|
|
git update-index --add "$2"
|
|
|
|
else
|
|
|
|
printf '%s' "$1" >"$2" &&
|
|
|
|
ln_s_obj=$(git hash-object -w "$2") &&
|
2015-02-23 18:14:47 +00:00
|
|
|
git update-index --add --cacheinfo 120000 $ln_s_obj "$2" &&
|
|
|
|
# pick up stat info from the file
|
|
|
|
git update-index "$2"
|
2013-06-07 20:53:27 +00:00
|
|
|
fi
|
|
|
|
}
|
2013-10-26 19:17:15 +00:00
|
|
|
|
2014-04-27 18:15:47 +00:00
|
|
|
# This function writes out its parameters, one per line
|
|
|
|
test_write_lines () {
|
|
|
|
printf "%s\n" "$@"
|
|
|
|
}
|
|
|
|
|
t: provide a perl() function which uses $PERL_PATH
Once upon a time, we assumed that calling a bare "perl" in
the test scripts was OK, because we would find the perl from
the user's PATH, and we were only asking that perl to do
basic operations that work even on old versions of perl.
Later, we found that some systems really prefer to use
$PERL_PATH even for these basic cases, because the system
perl misbehaves in some way (e.g., by handling line endings
differently). We then switched "perl" invocations to
"$PERL_PATH" to respect the user's choice.
Having to use "$PERL_PATH" is ugly and cumbersome, though.
Instead, let's provide a perl() shell function that tests
can use, which will transparently do the right thing.
Unfortunately, test writers still have to use $PERL_PATH in
certain situations, so we still need to keep the advice in
the README.
Note that this may fix test failures in t5004, t5503, t6002,
t6003, t6300, t8001, and t8002, depending on your system's
perl setup. All of these can be detected by running:
ln -s /bin/false bin-wrappers/perl
make test
which fails before this patch, and passes after.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-29 01:22:07 +00:00
|
|
|
perl () {
|
t: prevent '-x' tracing from interfering with test helpers' stderr
Running a test script with '-x' turns on 'set -x' tracing, the output
of which is normally sent to stderr. This causes a lot of
test failures, because many tests redirect and verify the stderr
of shell functions, most frequently that of 'test_must_fail'.
These issues were worked around somewhat in d88785e424 (test-lib: set
BASH_XTRACEFD automatically, 2016-05-11), so at least we could
reliably run tests with '-x' tracing under a Bash version supporting
BASH_XTRACEFD, i.e. v4.1 and later.
Futhermore, redirecting the stderr of test helper functions like
'test_must_fail' or 'test_expect_code' is the cause of a different
issue as well. If these functions detect something unexpected, they
will write their error messages intended to the user to thier stderr.
However, if their stderr is redirected in order to save and verify the
stderr of the tested git command invoked in the function, then the
function's error messages will be redirected as well. Consequently,
those messages won't reach the user, making the test's verbose output
less useful.
This patch makes it safe to redirect and verify the stderr of those
test helper functions which are meant to run the tested command given
as argument, even when running tests with '-x' and /bin/sh. This is
achieved through a couple of file descriptor redirections:
- Duplicate stderr of the tested command executed in the test helper
function from the function's fd 7 (see next point), to ensure that
the tested command's error messages go to a different fd than the
'-x' trace of the commands executed in the function or the
function's error messages.
- Duplicate the test helper function's fd 7 from the function's
original stderr, meaning that, after taking a detour through fd 7,
the error messages of the tested command do end up on the
function's original stderr.
- Duplicate stderr of the test helper function from fd 4, i.e. the
fd connected to the test script's original stderr and the fd used
for BASH_XTRACEFD. This ensures that the '-x' trace of the
commands executed in the function
- doesn't go to the function's original stderr, so it won't mess
with callers who want to save and verify the tested command's
stderr.
- does go to the same fd independently from the shell running
the test script, be it /bin/sh, an older Bash without
BASH_XTRACEFD, or a more recent Bash already supporting
BASH_XTRACEFD.
Furthermore, this also makes sure that the function's error
messages go to this fd 4, meaning that the user will be able to
see them even if the function's stderr is redirected in the test.
- Specify the latter two redirections above in the test helper
function's definition, so they are performed every time the
function is invoked, without the need to modify the callsites of
the function.
Perform these redirections in those test helper functions which can be
expected to have their stderr redirected, i.e. in the functions
'test_must_fail', 'test_might_fail', 'test_expect_code', 'test_env',
'nongit', 'test_terminal' and 'perl'. Note that 'test_might_fail',
'test_env', and 'nongit' are not involved in any test failures when
running tests with '-x' and /bin/sh.
The other test helper functions are left unchanged, because they
either don't run commands specified as their arguments, or redirecting
their stderr wouldn't make sense, or both.
With this change the number of failures when running the test suite
with '-x' tracing and /bin/sh goes down from 340 failed tests in 43
test scripts to 22 failed tests in 6 scripts (or 23 in 7, if the
system (OSX) uses an older Bash version without BASH_XTRACEFD to run
't9903-bash-prompt.sh').
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-25 13:40:15 +00:00
|
|
|
command "$PERL_PATH" "$@" 2>&7
|
|
|
|
} 7>&2 2>&4
|
2013-11-04 22:58:01 +00:00
|
|
|
|
tests: add 'test_bool_env' to catch non-bool GIT_TEST_* values
Since 3b072c577b (tests: replace test_tristate with "git env--helper",
2019-06-21) we get the normalized bool values of various GIT_TEST_*
environment variables via 'git env--helper'. Now, while the 'git
env--helper' command itself does catch invalid values in the
environment variable or in the given --default and exits with error
(exit code 128 or 129, respectively), it's invoked in conditions like
'if ! git env--helper ...', which means that all invalid bool values
are interpreted the same as the ordinary 'false' (exit code 1). This
has led to inadvertently skipped httpd tests in our CI builds for a
couple of weeks, see 3960290675 (ci: restore running httpd tests,
2019-09-06).
Let's be more careful about what the test suite accepts as bool values
in GIT_TEST_* environment variables, and error out loud and clear on
invalid values instead of simply skipping tests. Add the
'test_bool_env' helper function to encapsulate the invocation of 'git
env--helper' and the verification of its exit code, and replace all
invocations of that command in our test framework and test suite with
a call to this new helper (except in 't0017-env-helper.sh', of
course).
$ GIT_TEST_GIT_DAEMON=YesPlease ./t5570-git-daemon.sh
fatal: bad numeric config value 'YesPlease' for 'GIT_TEST_GIT_DAEMON': invalid unit
error: test_bool_env requires bool values both for $GIT_TEST_GIT_DAEMON and for the default fallback
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-22 13:14:36 +00:00
|
|
|
# Given the name of an environment variable with a bool value, normalize
|
|
|
|
# its value to a 0 (true) or 1 (false or empty string) return code.
|
|
|
|
#
|
|
|
|
# test_bool_env GIT_TEST_HTTPD <default-value>
|
|
|
|
#
|
|
|
|
# Return with code corresponding to the given default value if the variable
|
|
|
|
# is unset.
|
|
|
|
# Abort the test script if either the value of the variable or the default
|
|
|
|
# are not valid bool values.
|
|
|
|
|
|
|
|
test_bool_env () {
|
|
|
|
if test $# != 2
|
|
|
|
then
|
|
|
|
BUG "test_bool_env requires two parameters (variable name and default value)"
|
|
|
|
fi
|
|
|
|
|
2023-01-12 16:03:21 +00:00
|
|
|
test-tool env-helper --type=bool --default="$2" --exit-code "$1"
|
tests: add 'test_bool_env' to catch non-bool GIT_TEST_* values
Since 3b072c577b (tests: replace test_tristate with "git env--helper",
2019-06-21) we get the normalized bool values of various GIT_TEST_*
environment variables via 'git env--helper'. Now, while the 'git
env--helper' command itself does catch invalid values in the
environment variable or in the given --default and exits with error
(exit code 128 or 129, respectively), it's invoked in conditions like
'if ! git env--helper ...', which means that all invalid bool values
are interpreted the same as the ordinary 'false' (exit code 1). This
has led to inadvertently skipped httpd tests in our CI builds for a
couple of weeks, see 3960290675 (ci: restore running httpd tests,
2019-09-06).
Let's be more careful about what the test suite accepts as bool values
in GIT_TEST_* environment variables, and error out loud and clear on
invalid values instead of simply skipping tests. Add the
'test_bool_env' helper function to encapsulate the invocation of 'git
env--helper' and the verification of its exit code, and replace all
invocations of that command in our test framework and test suite with
a call to this new helper (except in 't0017-env-helper.sh', of
course).
$ GIT_TEST_GIT_DAEMON=YesPlease ./t5570-git-daemon.sh
fatal: bad numeric config value 'YesPlease' for 'GIT_TEST_GIT_DAEMON': invalid unit
error: test_bool_env requires bool values both for $GIT_TEST_GIT_DAEMON and for the default fallback
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-22 13:14:36 +00:00
|
|
|
ret=$?
|
|
|
|
case $ret in
|
|
|
|
0|1) # unset or valid bool value
|
|
|
|
;;
|
|
|
|
*) # invalid bool value or something unexpected
|
|
|
|
error >&7 "test_bool_env requires bool values both for \$$1 and for the default fallback"
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
return $ret
|
|
|
|
}
|
|
|
|
|
tests: turn on network daemon tests by default
We do not run the httpd nor git-daemon tests by default, as
they are rather heavyweight and require network access
(albeit over localhost). However, it would be nice if more
pepole ran them, for two reasons:
1. We would get more test coverage on more systems.
2. The point of the test suite is to find regressions. It
is very easy to change some of the underlying code and
break the httpd code without realizing you are even
affecting it. Running the httpd tests helps find these
problems sooner (ideally before the patches even hit
the list).
We still want to leave an "out", though, for people who really do
not want to run them. For that reason, the GIT_TEST_HTTPD and
GIT_TEST_GIT_DAEMON variables are now tri-state booleans
(true/false/auto), so you can say GIT_TEST_HTTPD=false to turn the
tests back off. To support those who want a stable single way to
disable these tests across versions of Git before and after this
change, an empty string explicitly set to these variables is also
taken as "false", so the behaviour changes only for those who:
a. did not express any preference by leaving these variables
unset. They did not test these features before, but now they
do; or
b. did express that they want to test these features by setting
GIT_TEST_FEATURE=false (or any equivalent other ways to tell
"false" to Git, e.g. "0"), which has been a valid but funny way
to say that they do want to test the feature only because we
used to interpret any non-empty string to mean "yes please
test". They no longer test that feature.
In addition, we are forgiving of common setup failures (e.g., you do
not have apache installed, or have an old version) when the
tri-state is "auto" (or unset), but report an error when it is
"true". This makes "auto" a sane default, as we should not cause
failures on setups where the tests cannot run. But it allows people
who use "true" to catch regressions in their system (e.g., they
uninstalled apache, but were expecting their automated test runs to
test git-httpd, and would want to be notified).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-10 21:29:37 +00:00
|
|
|
# Exit the test suite, either by skipping all remaining tests or by
|
2019-06-21 10:18:11 +00:00
|
|
|
# exiting with an error. If our prerequisite variable $1 falls back
|
|
|
|
# on a default assume we were opportunistically trying to set up some
|
|
|
|
# tests and we skip. If it is explicitly "true", then we report a failure.
|
tests: turn on network daemon tests by default
We do not run the httpd nor git-daemon tests by default, as
they are rather heavyweight and require network access
(albeit over localhost). However, it would be nice if more
pepole ran them, for two reasons:
1. We would get more test coverage on more systems.
2. The point of the test suite is to find regressions. It
is very easy to change some of the underlying code and
break the httpd code without realizing you are even
affecting it. Running the httpd tests helps find these
problems sooner (ideally before the patches even hit
the list).
We still want to leave an "out", though, for people who really do
not want to run them. For that reason, the GIT_TEST_HTTPD and
GIT_TEST_GIT_DAEMON variables are now tri-state booleans
(true/false/auto), so you can say GIT_TEST_HTTPD=false to turn the
tests back off. To support those who want a stable single way to
disable these tests across versions of Git before and after this
change, an empty string explicitly set to these variables is also
taken as "false", so the behaviour changes only for those who:
a. did not express any preference by leaving these variables
unset. They did not test these features before, but now they
do; or
b. did express that they want to test these features by setting
GIT_TEST_FEATURE=false (or any equivalent other ways to tell
"false" to Git, e.g. "0"), which has been a valid but funny way
to say that they do want to test the feature only because we
used to interpret any non-empty string to mean "yes please
test". They no longer test that feature.
In addition, we are forgiving of common setup failures (e.g., you do
not have apache installed, or have an old version) when the
tri-state is "auto" (or unset), but report an error when it is
"true". This makes "auto" a sane default, as we should not cause
failures on setups where the tests cannot run. But it allows people
who use "true" to catch regressions in their system (e.g., they
uninstalled apache, but were expecting their automated test runs to
test git-httpd, and would want to be notified).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-10 21:29:37 +00:00
|
|
|
#
|
|
|
|
# The error/skip message should be given by $2.
|
|
|
|
#
|
|
|
|
test_skip_or_die () {
|
tests: add 'test_bool_env' to catch non-bool GIT_TEST_* values
Since 3b072c577b (tests: replace test_tristate with "git env--helper",
2019-06-21) we get the normalized bool values of various GIT_TEST_*
environment variables via 'git env--helper'. Now, while the 'git
env--helper' command itself does catch invalid values in the
environment variable or in the given --default and exits with error
(exit code 128 or 129, respectively), it's invoked in conditions like
'if ! git env--helper ...', which means that all invalid bool values
are interpreted the same as the ordinary 'false' (exit code 1). This
has led to inadvertently skipped httpd tests in our CI builds for a
couple of weeks, see 3960290675 (ci: restore running httpd tests,
2019-09-06).
Let's be more careful about what the test suite accepts as bool values
in GIT_TEST_* environment variables, and error out loud and clear on
invalid values instead of simply skipping tests. Add the
'test_bool_env' helper function to encapsulate the invocation of 'git
env--helper' and the verification of its exit code, and replace all
invocations of that command in our test framework and test suite with
a call to this new helper (except in 't0017-env-helper.sh', of
course).
$ GIT_TEST_GIT_DAEMON=YesPlease ./t5570-git-daemon.sh
fatal: bad numeric config value 'YesPlease' for 'GIT_TEST_GIT_DAEMON': invalid unit
error: test_bool_env requires bool values both for $GIT_TEST_GIT_DAEMON and for the default fallback
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-22 13:14:36 +00:00
|
|
|
if ! test_bool_env "$1" false
|
2019-06-21 10:18:11 +00:00
|
|
|
then
|
tests: turn on network daemon tests by default
We do not run the httpd nor git-daemon tests by default, as
they are rather heavyweight and require network access
(albeit over localhost). However, it would be nice if more
pepole ran them, for two reasons:
1. We would get more test coverage on more systems.
2. The point of the test suite is to find regressions. It
is very easy to change some of the underlying code and
break the httpd code without realizing you are even
affecting it. Running the httpd tests helps find these
problems sooner (ideally before the patches even hit
the list).
We still want to leave an "out", though, for people who really do
not want to run them. For that reason, the GIT_TEST_HTTPD and
GIT_TEST_GIT_DAEMON variables are now tri-state booleans
(true/false/auto), so you can say GIT_TEST_HTTPD=false to turn the
tests back off. To support those who want a stable single way to
disable these tests across versions of Git before and after this
change, an empty string explicitly set to these variables is also
taken as "false", so the behaviour changes only for those who:
a. did not express any preference by leaving these variables
unset. They did not test these features before, but now they
do; or
b. did express that they want to test these features by setting
GIT_TEST_FEATURE=false (or any equivalent other ways to tell
"false" to Git, e.g. "0"), which has been a valid but funny way
to say that they do want to test the feature only because we
used to interpret any non-empty string to mean "yes please
test". They no longer test that feature.
In addition, we are forgiving of common setup failures (e.g., you do
not have apache installed, or have an old version) when the
tri-state is "auto" (or unset), but report an error when it is
"true". This makes "auto" a sane default, as we should not cause
failures on setups where the tests cannot run. But it allows people
who use "true" to catch regressions in their system (e.g., they
uninstalled apache, but were expecting their automated test runs to
test git-httpd, and would want to be notified).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-10 21:29:37 +00:00
|
|
|
skip_all=$2
|
|
|
|
test_done
|
2019-06-21 10:18:11 +00:00
|
|
|
fi
|
|
|
|
error "$2"
|
tests: turn on network daemon tests by default
We do not run the httpd nor git-daemon tests by default, as
they are rather heavyweight and require network access
(albeit over localhost). However, it would be nice if more
pepole ran them, for two reasons:
1. We would get more test coverage on more systems.
2. The point of the test suite is to find regressions. It
is very easy to change some of the underlying code and
break the httpd code without realizing you are even
affecting it. Running the httpd tests helps find these
problems sooner (ideally before the patches even hit
the list).
We still want to leave an "out", though, for people who really do
not want to run them. For that reason, the GIT_TEST_HTTPD and
GIT_TEST_GIT_DAEMON variables are now tri-state booleans
(true/false/auto), so you can say GIT_TEST_HTTPD=false to turn the
tests back off. To support those who want a stable single way to
disable these tests across versions of Git before and after this
change, an empty string explicitly set to these variables is also
taken as "false", so the behaviour changes only for those who:
a. did not express any preference by leaving these variables
unset. They did not test these features before, but now they
do; or
b. did express that they want to test these features by setting
GIT_TEST_FEATURE=false (or any equivalent other ways to tell
"false" to Git, e.g. "0"), which has been a valid but funny way
to say that they do want to test the feature only because we
used to interpret any non-empty string to mean "yes please
test". They no longer test that feature.
In addition, we are forgiving of common setup failures (e.g., you do
not have apache installed, or have an old version) when the
tri-state is "auto" (or unset), but report an error when it is
"true". This makes "auto" a sane default, as we should not cause
failures on setups where the tests cannot run. But it allows people
who use "true" to catch regressions in their system (e.g., they
uninstalled apache, but were expecting their automated test runs to
test git-httpd, and would want to be notified).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-10 21:29:37 +00:00
|
|
|
}
|
|
|
|
|
2016-06-01 07:04:26 +00:00
|
|
|
# Like "env FOO=BAR some-program", but run inside a subshell, which means
|
|
|
|
# it also works for shell functions (though those functions cannot impact
|
|
|
|
# the environment outside of the test_env invocation).
|
|
|
|
test_env () {
|
|
|
|
(
|
|
|
|
while test $# -gt 0
|
|
|
|
do
|
|
|
|
case "$1" in
|
|
|
|
*=*)
|
|
|
|
eval "${1%%=*}=\${1#*=}"
|
|
|
|
eval "export ${1%%=*}"
|
|
|
|
shift
|
|
|
|
;;
|
|
|
|
*)
|
t: prevent '-x' tracing from interfering with test helpers' stderr
Running a test script with '-x' turns on 'set -x' tracing, the output
of which is normally sent to stderr. This causes a lot of
test failures, because many tests redirect and verify the stderr
of shell functions, most frequently that of 'test_must_fail'.
These issues were worked around somewhat in d88785e424 (test-lib: set
BASH_XTRACEFD automatically, 2016-05-11), so at least we could
reliably run tests with '-x' tracing under a Bash version supporting
BASH_XTRACEFD, i.e. v4.1 and later.
Futhermore, redirecting the stderr of test helper functions like
'test_must_fail' or 'test_expect_code' is the cause of a different
issue as well. If these functions detect something unexpected, they
will write their error messages intended to the user to thier stderr.
However, if their stderr is redirected in order to save and verify the
stderr of the tested git command invoked in the function, then the
function's error messages will be redirected as well. Consequently,
those messages won't reach the user, making the test's verbose output
less useful.
This patch makes it safe to redirect and verify the stderr of those
test helper functions which are meant to run the tested command given
as argument, even when running tests with '-x' and /bin/sh. This is
achieved through a couple of file descriptor redirections:
- Duplicate stderr of the tested command executed in the test helper
function from the function's fd 7 (see next point), to ensure that
the tested command's error messages go to a different fd than the
'-x' trace of the commands executed in the function or the
function's error messages.
- Duplicate the test helper function's fd 7 from the function's
original stderr, meaning that, after taking a detour through fd 7,
the error messages of the tested command do end up on the
function's original stderr.
- Duplicate stderr of the test helper function from fd 4, i.e. the
fd connected to the test script's original stderr and the fd used
for BASH_XTRACEFD. This ensures that the '-x' trace of the
commands executed in the function
- doesn't go to the function's original stderr, so it won't mess
with callers who want to save and verify the tested command's
stderr.
- does go to the same fd independently from the shell running
the test script, be it /bin/sh, an older Bash without
BASH_XTRACEFD, or a more recent Bash already supporting
BASH_XTRACEFD.
Furthermore, this also makes sure that the function's error
messages go to this fd 4, meaning that the user will be able to
see them even if the function's stderr is redirected in the test.
- Specify the latter two redirections above in the test helper
function's definition, so they are performed every time the
function is invoked, without the need to modify the callsites of
the function.
Perform these redirections in those test helper functions which can be
expected to have their stderr redirected, i.e. in the functions
'test_must_fail', 'test_might_fail', 'test_expect_code', 'test_env',
'nongit', 'test_terminal' and 'perl'. Note that 'test_might_fail',
'test_env', and 'nongit' are not involved in any test failures when
running tests with '-x' and /bin/sh.
The other test helper functions are left unchanged, because they
either don't run commands specified as their arguments, or redirecting
their stderr wouldn't make sense, or both.
With this change the number of failures when running the test suite
with '-x' tracing and /bin/sh goes down from 340 failed tests in 43
test scripts to 22 failed tests in 6 scripts (or 23 in 7, if the
system (OSX) uses an older Bash version without BASH_XTRACEFD to run
't9903-bash-prompt.sh').
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-25 13:40:15 +00:00
|
|
|
"$@" 2>&7
|
2016-06-01 07:04:26 +00:00
|
|
|
exit
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
done
|
|
|
|
)
|
t: prevent '-x' tracing from interfering with test helpers' stderr
Running a test script with '-x' turns on 'set -x' tracing, the output
of which is normally sent to stderr. This causes a lot of
test failures, because many tests redirect and verify the stderr
of shell functions, most frequently that of 'test_must_fail'.
These issues were worked around somewhat in d88785e424 (test-lib: set
BASH_XTRACEFD automatically, 2016-05-11), so at least we could
reliably run tests with '-x' tracing under a Bash version supporting
BASH_XTRACEFD, i.e. v4.1 and later.
Futhermore, redirecting the stderr of test helper functions like
'test_must_fail' or 'test_expect_code' is the cause of a different
issue as well. If these functions detect something unexpected, they
will write their error messages intended to the user to thier stderr.
However, if their stderr is redirected in order to save and verify the
stderr of the tested git command invoked in the function, then the
function's error messages will be redirected as well. Consequently,
those messages won't reach the user, making the test's verbose output
less useful.
This patch makes it safe to redirect and verify the stderr of those
test helper functions which are meant to run the tested command given
as argument, even when running tests with '-x' and /bin/sh. This is
achieved through a couple of file descriptor redirections:
- Duplicate stderr of the tested command executed in the test helper
function from the function's fd 7 (see next point), to ensure that
the tested command's error messages go to a different fd than the
'-x' trace of the commands executed in the function or the
function's error messages.
- Duplicate the test helper function's fd 7 from the function's
original stderr, meaning that, after taking a detour through fd 7,
the error messages of the tested command do end up on the
function's original stderr.
- Duplicate stderr of the test helper function from fd 4, i.e. the
fd connected to the test script's original stderr and the fd used
for BASH_XTRACEFD. This ensures that the '-x' trace of the
commands executed in the function
- doesn't go to the function's original stderr, so it won't mess
with callers who want to save and verify the tested command's
stderr.
- does go to the same fd independently from the shell running
the test script, be it /bin/sh, an older Bash without
BASH_XTRACEFD, or a more recent Bash already supporting
BASH_XTRACEFD.
Furthermore, this also makes sure that the function's error
messages go to this fd 4, meaning that the user will be able to
see them even if the function's stderr is redirected in the test.
- Specify the latter two redirections above in the test helper
function's definition, so they are performed every time the
function is invoked, without the need to modify the callsites of
the function.
Perform these redirections in those test helper functions which can be
expected to have their stderr redirected, i.e. in the functions
'test_must_fail', 'test_might_fail', 'test_expect_code', 'test_env',
'nongit', 'test_terminal' and 'perl'. Note that 'test_might_fail',
'test_env', and 'nongit' are not involved in any test failures when
running tests with '-x' and /bin/sh.
The other test helper functions are left unchanged, because they
either don't run commands specified as their arguments, or redirecting
their stderr wouldn't make sense, or both.
With this change the number of failures when running the test suite
with '-x' tracing and /bin/sh goes down from 340 failed tests in 43
test scripts to 22 failed tests in 6 scripts (or 23 in 7, if the
system (OSX) uses an older Bash version without BASH_XTRACEFD to run
't9903-bash-prompt.sh').
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-25 13:40:15 +00:00
|
|
|
} 7>&2 2>&4
|
t9300: factor out portable "head -c" replacement
It is sometimes useful to be able to read exactly N bytes from a
pipe. Doing this portably turns out to be surprisingly difficult
in shell scripts.
We want a solution that:
- is portable
- never reads more than N bytes due to buffering (which
would mean those bytes are not available to the next
program to read from the same pipe)
- handles partial reads by looping until N bytes are read
(or we see EOF)
- is resilient to stray signals giving us EINTR while
trying to read (even though we don't send them, things
like SIGWINCH could cause apparently-random failures)
Some possible solutions are:
- "head -c" is not portable, and implementations may
buffer (though GNU head does not)
- "read -N" is a bash-ism, and thus not portable
- "dd bs=$n count=1" does not handle partial reads. GNU dd
has iflags=fullblock, but that is not portable
- "dd bs=1 count=$n" fixes the partial read problem (all
reads are 1-byte, so there can be no partial response).
It does make a lot of write() calls, but for our tests
that's unlikely to matter. It's fairly portable. We
already use it in our tests, and it's unlikely that
implementations would screw up any of our criteria. The
most unknown one would be signal handling.
- perl can do a sysread() loop pretty easily. On my Linux
system, at least, it seems to restart the read() call
automatically. If that turns out not to be portable,
though, it would be easy for us to handle it.
That makes the perl solution the least bad (because we
conveniently omitted "length of code" as a criterion).
It's also what t9300 is currently using, so we can just pull
the implementation from there.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 09:07:54 +00:00
|
|
|
|
2016-06-30 08:16:18 +00:00
|
|
|
# Returns true if the numeric exit code in "$2" represents the expected signal
|
|
|
|
# in "$1". Signals should be given numerically.
|
|
|
|
test_match_signal () {
|
|
|
|
if test "$2" = "$((128 + $1))"
|
|
|
|
then
|
|
|
|
# POSIX
|
|
|
|
return 0
|
|
|
|
elif test "$2" = "$((256 + $1))"
|
|
|
|
then
|
|
|
|
# ksh
|
|
|
|
return 0
|
|
|
|
fi
|
|
|
|
return 1
|
|
|
|
}
|
2016-07-19 20:22:20 +00:00
|
|
|
|
t9300: factor out portable "head -c" replacement
It is sometimes useful to be able to read exactly N bytes from a
pipe. Doing this portably turns out to be surprisingly difficult
in shell scripts.
We want a solution that:
- is portable
- never reads more than N bytes due to buffering (which
would mean those bytes are not available to the next
program to read from the same pipe)
- handles partial reads by looping until N bytes are read
(or we see EOF)
- is resilient to stray signals giving us EINTR while
trying to read (even though we don't send them, things
like SIGWINCH could cause apparently-random failures)
Some possible solutions are:
- "head -c" is not portable, and implementations may
buffer (though GNU head does not)
- "read -N" is a bash-ism, and thus not portable
- "dd bs=$n count=1" does not handle partial reads. GNU dd
has iflags=fullblock, but that is not portable
- "dd bs=1 count=$n" fixes the partial read problem (all
reads are 1-byte, so there can be no partial response).
It does make a lot of write() calls, but for our tests
that's unlikely to matter. It's fairly portable. We
already use it in our tests, and it's unlikely that
implementations would screw up any of our criteria. The
most unknown one would be signal handling.
- perl can do a sysread() loop pretty easily. On my Linux
system, at least, it seems to restart the read() call
automatically. If that turns out not to be portable,
though, it would be easy for us to handle it.
That makes the perl solution the least bad (because we
conveniently omitted "length of code" as a criterion).
It's also what t9300 is currently using, so we can just pull
the implementation from there.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 09:07:54 +00:00
|
|
|
# Read up to "$1" bytes (or to EOF) from stdin and write them to stdout.
|
|
|
|
test_copy_bytes () {
|
|
|
|
perl -e '
|
|
|
|
my $len = $ARGV[1];
|
|
|
|
while ($len > 0) {
|
|
|
|
my $s;
|
|
|
|
my $nread = sysread(STDIN, $s, $len);
|
|
|
|
die "cannot read: $!" unless defined($nread);
|
2017-07-16 10:45:32 +00:00
|
|
|
last unless $nread;
|
t9300: factor out portable "head -c" replacement
It is sometimes useful to be able to read exactly N bytes from a
pipe. Doing this portably turns out to be surprisingly difficult
in shell scripts.
We want a solution that:
- is portable
- never reads more than N bytes due to buffering (which
would mean those bytes are not available to the next
program to read from the same pipe)
- handles partial reads by looping until N bytes are read
(or we see EOF)
- is resilient to stray signals giving us EINTR while
trying to read (even though we don't send them, things
like SIGWINCH could cause apparently-random failures)
Some possible solutions are:
- "head -c" is not portable, and implementations may
buffer (though GNU head does not)
- "read -N" is a bash-ism, and thus not portable
- "dd bs=$n count=1" does not handle partial reads. GNU dd
has iflags=fullblock, but that is not portable
- "dd bs=1 count=$n" fixes the partial read problem (all
reads are 1-byte, so there can be no partial response).
It does make a lot of write() calls, but for our tests
that's unlikely to matter. It's fairly portable. We
already use it in our tests, and it's unlikely that
implementations would screw up any of our criteria. The
most unknown one would be signal handling.
- perl can do a sysread() loop pretty easily. On my Linux
system, at least, it seems to restart the read() call
automatically. If that turns out not to be portable,
though, it would be easy for us to handle it.
That makes the perl solution the least bad (because we
conveniently omitted "length of code" as a criterion).
It's also what t9300 is currently using, so we can just pull
the implementation from there.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 09:07:54 +00:00
|
|
|
print $s;
|
|
|
|
$len -= $nread;
|
|
|
|
}
|
|
|
|
' - "$1"
|
|
|
|
}
|
2016-12-16 02:30:12 +00:00
|
|
|
|
|
|
|
# run "$@" inside a non-git directory
|
|
|
|
nongit () {
|
|
|
|
test -d non-repo ||
|
|
|
|
mkdir non-repo ||
|
|
|
|
return 1
|
|
|
|
|
|
|
|
(
|
|
|
|
GIT_CEILING_DIRECTORIES=$(pwd) &&
|
|
|
|
export GIT_CEILING_DIRECTORIES &&
|
|
|
|
cd non-repo &&
|
t: prevent '-x' tracing from interfering with test helpers' stderr
Running a test script with '-x' turns on 'set -x' tracing, the output
of which is normally sent to stderr. This causes a lot of
test failures, because many tests redirect and verify the stderr
of shell functions, most frequently that of 'test_must_fail'.
These issues were worked around somewhat in d88785e424 (test-lib: set
BASH_XTRACEFD automatically, 2016-05-11), so at least we could
reliably run tests with '-x' tracing under a Bash version supporting
BASH_XTRACEFD, i.e. v4.1 and later.
Futhermore, redirecting the stderr of test helper functions like
'test_must_fail' or 'test_expect_code' is the cause of a different
issue as well. If these functions detect something unexpected, they
will write their error messages intended to the user to thier stderr.
However, if their stderr is redirected in order to save and verify the
stderr of the tested git command invoked in the function, then the
function's error messages will be redirected as well. Consequently,
those messages won't reach the user, making the test's verbose output
less useful.
This patch makes it safe to redirect and verify the stderr of those
test helper functions which are meant to run the tested command given
as argument, even when running tests with '-x' and /bin/sh. This is
achieved through a couple of file descriptor redirections:
- Duplicate stderr of the tested command executed in the test helper
function from the function's fd 7 (see next point), to ensure that
the tested command's error messages go to a different fd than the
'-x' trace of the commands executed in the function or the
function's error messages.
- Duplicate the test helper function's fd 7 from the function's
original stderr, meaning that, after taking a detour through fd 7,
the error messages of the tested command do end up on the
function's original stderr.
- Duplicate stderr of the test helper function from fd 4, i.e. the
fd connected to the test script's original stderr and the fd used
for BASH_XTRACEFD. This ensures that the '-x' trace of the
commands executed in the function
- doesn't go to the function's original stderr, so it won't mess
with callers who want to save and verify the tested command's
stderr.
- does go to the same fd independently from the shell running
the test script, be it /bin/sh, an older Bash without
BASH_XTRACEFD, or a more recent Bash already supporting
BASH_XTRACEFD.
Furthermore, this also makes sure that the function's error
messages go to this fd 4, meaning that the user will be able to
see them even if the function's stderr is redirected in the test.
- Specify the latter two redirections above in the test helper
function's definition, so they are performed every time the
function is invoked, without the need to modify the callsites of
the function.
Perform these redirections in those test helper functions which can be
expected to have their stderr redirected, i.e. in the functions
'test_must_fail', 'test_might_fail', 'test_expect_code', 'test_env',
'nongit', 'test_terminal' and 'perl'. Note that 'test_might_fail',
'test_env', and 'nongit' are not involved in any test failures when
running tests with '-x' and /bin/sh.
The other test helper functions are left unchanged, because they
either don't run commands specified as their arguments, or redirecting
their stderr wouldn't make sense, or both.
With this change the number of failures when running the test suite
with '-x' tracing and /bin/sh goes down from 340 failed tests in 43
test scripts to 22 failed tests in 6 scripts (or 23 in 7, if the
system (OSX) uses an older Bash version without BASH_XTRACEFD to run
't9903-bash-prompt.sh').
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-25 13:40:15 +00:00
|
|
|
"$@" 2>&7
|
2016-12-16 02:30:12 +00:00
|
|
|
)
|
t: prevent '-x' tracing from interfering with test helpers' stderr
Running a test script with '-x' turns on 'set -x' tracing, the output
of which is normally sent to stderr. This causes a lot of
test failures, because many tests redirect and verify the stderr
of shell functions, most frequently that of 'test_must_fail'.
These issues were worked around somewhat in d88785e424 (test-lib: set
BASH_XTRACEFD automatically, 2016-05-11), so at least we could
reliably run tests with '-x' tracing under a Bash version supporting
BASH_XTRACEFD, i.e. v4.1 and later.
Futhermore, redirecting the stderr of test helper functions like
'test_must_fail' or 'test_expect_code' is the cause of a different
issue as well. If these functions detect something unexpected, they
will write their error messages intended to the user to thier stderr.
However, if their stderr is redirected in order to save and verify the
stderr of the tested git command invoked in the function, then the
function's error messages will be redirected as well. Consequently,
those messages won't reach the user, making the test's verbose output
less useful.
This patch makes it safe to redirect and verify the stderr of those
test helper functions which are meant to run the tested command given
as argument, even when running tests with '-x' and /bin/sh. This is
achieved through a couple of file descriptor redirections:
- Duplicate stderr of the tested command executed in the test helper
function from the function's fd 7 (see next point), to ensure that
the tested command's error messages go to a different fd than the
'-x' trace of the commands executed in the function or the
function's error messages.
- Duplicate the test helper function's fd 7 from the function's
original stderr, meaning that, after taking a detour through fd 7,
the error messages of the tested command do end up on the
function's original stderr.
- Duplicate stderr of the test helper function from fd 4, i.e. the
fd connected to the test script's original stderr and the fd used
for BASH_XTRACEFD. This ensures that the '-x' trace of the
commands executed in the function
- doesn't go to the function's original stderr, so it won't mess
with callers who want to save and verify the tested command's
stderr.
- does go to the same fd independently from the shell running
the test script, be it /bin/sh, an older Bash without
BASH_XTRACEFD, or a more recent Bash already supporting
BASH_XTRACEFD.
Furthermore, this also makes sure that the function's error
messages go to this fd 4, meaning that the user will be able to
see them even if the function's stderr is redirected in the test.
- Specify the latter two redirections above in the test helper
function's definition, so they are performed every time the
function is invoked, without the need to modify the callsites of
the function.
Perform these redirections in those test helper functions which can be
expected to have their stderr redirected, i.e. in the functions
'test_must_fail', 'test_might_fail', 'test_expect_code', 'test_env',
'nongit', 'test_terminal' and 'perl'. Note that 'test_might_fail',
'test_env', and 'nongit' are not involved in any test failures when
running tests with '-x' and /bin/sh.
The other test helper functions are left unchanged, because they
either don't run commands specified as their arguments, or redirecting
their stderr wouldn't make sense, or both.
With this change the number of failures when running the test suite
with '-x' tracing and /bin/sh goes down from 340 failed tests in 43
test scripts to 22 failed tests in 6 scripts (or 23 in 7, if the
system (OSX) uses an older Bash version without BASH_XTRACEFD to run
't9903-bash-prompt.sh').
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-25 13:40:15 +00:00
|
|
|
} 7>&2 2>&4
|
t/lib-git-daemon: add network-protocol helpers
All of our git-protocol tests rely on invoking the client
and having it make a request of a server. That gives a nice
real-world test of how the two behave together, but it
doesn't leave any room for testing how a server might react
to _other_ clients.
Let's add a few test helper functions which can be used to
manually conduct a git-protocol conversation with a remote
git-daemon:
1. To connect to a remote git-daemon, we need something
like "netcat". But not everybody will have netcat. And
even if they do, the behavior with respect to
half-duplex shutdowns is not portable (openbsd netcat
has "-N", with others you must rely on "-q 1", which is
racy).
Here we provide a "fake_nc" that is capable of doing
a client-side netcat, with sane half-duplex semantics.
It relies on perl's IO::Socket::INET. That's been in
the base distribution since 5.6.0, so it's probably
available everywhere. But just to be on the safe side,
we'll add a prereq.
2. To help tests speak and read pktline, this patch adds
packetize() and depacketize() functions.
I've put fake_nc() into lib-git-daemon.sh, since that's
really the only server where we'd need to use a network
socket. Whereas the pktline helpers may be of more general
use, so I've added them to test-lib-functions.sh. Programs
like upload-pack speak pktline, but can talk directly over
stdio without a network socket.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-25 00:58:19 +00:00
|
|
|
|
2021-07-16 15:41:33 +00:00
|
|
|
# These functions are historical wrappers around "test-tool pkt-line"
|
|
|
|
# for older tests. Use "test-tool pkt-line" itself in new tests.
|
2020-12-01 00:46:49 +00:00
|
|
|
packetize () {
|
2020-03-27 08:03:00 +00:00
|
|
|
if test $# -gt 0
|
|
|
|
then
|
|
|
|
packet="$*"
|
|
|
|
printf '%04x%s' "$((4 + ${#packet}))" "$packet"
|
|
|
|
else
|
2021-07-16 15:41:33 +00:00
|
|
|
test-tool pkt-line pack
|
2020-03-27 08:03:00 +00:00
|
|
|
fi
|
t/lib-git-daemon: add network-protocol helpers
All of our git-protocol tests rely on invoking the client
and having it make a request of a server. That gives a nice
real-world test of how the two behave together, but it
doesn't leave any room for testing how a server might react
to _other_ clients.
Let's add a few test helper functions which can be used to
manually conduct a git-protocol conversation with a remote
git-daemon:
1. To connect to a remote git-daemon, we need something
like "netcat". But not everybody will have netcat. And
even if they do, the behavior with respect to
half-duplex shutdowns is not portable (openbsd netcat
has "-N", with others you must rely on "-q 1", which is
racy).
Here we provide a "fake_nc" that is capable of doing
a client-side netcat, with sane half-duplex semantics.
It relies on perl's IO::Socket::INET. That's been in
the base distribution since 5.6.0, so it's probably
available everywhere. But just to be on the safe side,
we'll add a prereq.
2. To help tests speak and read pktline, this patch adds
packetize() and depacketize() functions.
I've put fake_nc() into lib-git-daemon.sh, since that's
really the only server where we'd need to use a network
socket. Whereas the pktline helpers may be of more general
use, so I've added them to test-lib-functions.sh. Programs
like upload-pack speak pktline, but can talk directly over
stdio without a network socket.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-25 00:58:19 +00:00
|
|
|
}
|
|
|
|
|
2021-07-16 15:41:33 +00:00
|
|
|
packetize_raw () {
|
|
|
|
test-tool pkt-line pack-raw-stdin
|
|
|
|
}
|
|
|
|
|
t/lib-git-daemon: add network-protocol helpers
All of our git-protocol tests rely on invoking the client
and having it make a request of a server. That gives a nice
real-world test of how the two behave together, but it
doesn't leave any room for testing how a server might react
to _other_ clients.
Let's add a few test helper functions which can be used to
manually conduct a git-protocol conversation with a remote
git-daemon:
1. To connect to a remote git-daemon, we need something
like "netcat". But not everybody will have netcat. And
even if they do, the behavior with respect to
half-duplex shutdowns is not portable (openbsd netcat
has "-N", with others you must rely on "-q 1", which is
racy).
Here we provide a "fake_nc" that is capable of doing
a client-side netcat, with sane half-duplex semantics.
It relies on perl's IO::Socket::INET. That's been in
the base distribution since 5.6.0, so it's probably
available everywhere. But just to be on the safe side,
we'll add a prereq.
2. To help tests speak and read pktline, this patch adds
packetize() and depacketize() functions.
I've put fake_nc() into lib-git-daemon.sh, since that's
really the only server where we'd need to use a network
socket. Whereas the pktline helpers may be of more general
use, so I've added them to test-lib-functions.sh. Programs
like upload-pack speak pktline, but can talk directly over
stdio without a network socket.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-25 00:58:19 +00:00
|
|
|
depacketize () {
|
2021-07-16 15:41:33 +00:00
|
|
|
test-tool pkt-line unpack
|
t/lib-git-daemon: add network-protocol helpers
All of our git-protocol tests rely on invoking the client
and having it make a request of a server. That gives a nice
real-world test of how the two behave together, but it
doesn't leave any room for testing how a server might react
to _other_ clients.
Let's add a few test helper functions which can be used to
manually conduct a git-protocol conversation with a remote
git-daemon:
1. To connect to a remote git-daemon, we need something
like "netcat". But not everybody will have netcat. And
even if they do, the behavior with respect to
half-duplex shutdowns is not portable (openbsd netcat
has "-N", with others you must rely on "-q 1", which is
racy).
Here we provide a "fake_nc" that is capable of doing
a client-side netcat, with sane half-duplex semantics.
It relies on perl's IO::Socket::INET. That's been in
the base distribution since 5.6.0, so it's probably
available everywhere. But just to be on the safe side,
we'll add a prereq.
2. To help tests speak and read pktline, this patch adds
packetize() and depacketize() functions.
I've put fake_nc() into lib-git-daemon.sh, since that's
really the only server where we'd need to use a network
socket. Whereas the pktline helpers may be of more general
use, so I've added them to test-lib-functions.sh. Programs
like upload-pack speak pktline, but can talk directly over
stdio without a network socket.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-25 00:58:19 +00:00
|
|
|
}
|
t: add test functions to translate hash-related values
Add several test functions to make working with various hash-related
values easier.
Add test_oid_init, which loads common hash-related constants and
placeholder object IDs from the newly added files in t/oid-info.
Provide values for these constants for both SHA-1 and SHA-256.
Add test_oid_cache, which accepts data on standard input in the form of
hash-specific key-value pairs that can be looked up later, using the
same format as the files in t/oid-info. Document this format in a
t/oid-info/README directory so that it's easier to use in the future.
Add test_oid, which is used to specify look up a per-hash value
(produced on standard output) based on the key specified as its
argument. Usually the data to be looked up will be a hash-related
constant (such as the size of the hash in binary or hexadecimal), a
well-known or placeholder object ID (such as the all-zeros object ID or
one consisting of "deadbeef" repeated), or something similar. For these
reasons, test_oid will usually be used within a command substitution.
Consequently, redirect the error output to standard error, since
otherwise it will not be displayed.
Add test_detect_hash, which currently only detects SHA-1, and
test_set_hash, which can be used to set a different hash algorithm for
test purposes. In the future, test_detect_hash will learn to actually
detect the hash depending on how the testsuite is to be run.
Use the local keyword within these functions to avoid overwriting other
shell variables. We have had a test balloon in place for a couple of
releases to catch shells that don't have this keyword and have not
received any reports of failure. Note that the varying usages of local
used here are supported by all common open-source shells supporting the
local keyword.
Test these new functions as part of t0000, which also serves to
demonstrate basic usage of them. In addition, add documentation on how
to format the lookup data and how to use the test functions.
Implement two basic lookup charts, one for common invalid or synthesized
object IDs, and one for various facts about the hash function in use.
Provide versions of the data for both SHA-1 and SHA-256.
Since we use shell variables for storage, names used for lookup can
currently consist only of shell identifier characters. If this is a
problem in the future, we can hash the names before use.
Improved-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-13 05:17:31 +00:00
|
|
|
|
2019-04-05 03:37:42 +00:00
|
|
|
# Converts base-16 data into base-8. The output is given as a sequence of
|
|
|
|
# escaped octals, suitable for consumption by 'printf'.
|
|
|
|
hex2oct () {
|
|
|
|
perl -ne 'printf "\\%03o", hex for /../g'
|
|
|
|
}
|
|
|
|
|
t: add test functions to translate hash-related values
Add several test functions to make working with various hash-related
values easier.
Add test_oid_init, which loads common hash-related constants and
placeholder object IDs from the newly added files in t/oid-info.
Provide values for these constants for both SHA-1 and SHA-256.
Add test_oid_cache, which accepts data on standard input in the form of
hash-specific key-value pairs that can be looked up later, using the
same format as the files in t/oid-info. Document this format in a
t/oid-info/README directory so that it's easier to use in the future.
Add test_oid, which is used to specify look up a per-hash value
(produced on standard output) based on the key specified as its
argument. Usually the data to be looked up will be a hash-related
constant (such as the size of the hash in binary or hexadecimal), a
well-known or placeholder object ID (such as the all-zeros object ID or
one consisting of "deadbeef" repeated), or something similar. For these
reasons, test_oid will usually be used within a command substitution.
Consequently, redirect the error output to standard error, since
otherwise it will not be displayed.
Add test_detect_hash, which currently only detects SHA-1, and
test_set_hash, which can be used to set a different hash algorithm for
test purposes. In the future, test_detect_hash will learn to actually
detect the hash depending on how the testsuite is to be run.
Use the local keyword within these functions to avoid overwriting other
shell variables. We have had a test balloon in place for a couple of
releases to catch shells that don't have this keyword and have not
received any reports of failure. Note that the varying usages of local
used here are supported by all common open-source shells supporting the
local keyword.
Test these new functions as part of t0000, which also serves to
demonstrate basic usage of them. In addition, add documentation on how
to format the lookup data and how to use the test functions.
Implement two basic lookup charts, one for common invalid or synthesized
object IDs, and one for various facts about the hash function in use.
Provide versions of the data for both SHA-1 and SHA-256.
Since we use shell variables for storage, names used for lookup can
currently consist only of shell identifier characters. If this is a
problem in the future, we can hash the names before use.
Improved-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-13 05:17:31 +00:00
|
|
|
# Set the hash algorithm in use to $1. Only useful when testing the testsuite.
|
|
|
|
test_set_hash () {
|
|
|
|
test_hash_algo="$1"
|
|
|
|
}
|
|
|
|
|
|
|
|
# Detect the hash algorithm in use.
|
|
|
|
test_detect_hash () {
|
2020-07-29 23:14:24 +00:00
|
|
|
test_hash_algo="${GIT_TEST_DEFAULT_HASH:-sha1}"
|
t: add test functions to translate hash-related values
Add several test functions to make working with various hash-related
values easier.
Add test_oid_init, which loads common hash-related constants and
placeholder object IDs from the newly added files in t/oid-info.
Provide values for these constants for both SHA-1 and SHA-256.
Add test_oid_cache, which accepts data on standard input in the form of
hash-specific key-value pairs that can be looked up later, using the
same format as the files in t/oid-info. Document this format in a
t/oid-info/README directory so that it's easier to use in the future.
Add test_oid, which is used to specify look up a per-hash value
(produced on standard output) based on the key specified as its
argument. Usually the data to be looked up will be a hash-related
constant (such as the size of the hash in binary or hexadecimal), a
well-known or placeholder object ID (such as the all-zeros object ID or
one consisting of "deadbeef" repeated), or something similar. For these
reasons, test_oid will usually be used within a command substitution.
Consequently, redirect the error output to standard error, since
otherwise it will not be displayed.
Add test_detect_hash, which currently only detects SHA-1, and
test_set_hash, which can be used to set a different hash algorithm for
test purposes. In the future, test_detect_hash will learn to actually
detect the hash depending on how the testsuite is to be run.
Use the local keyword within these functions to avoid overwriting other
shell variables. We have had a test balloon in place for a couple of
releases to catch shells that don't have this keyword and have not
received any reports of failure. Note that the varying usages of local
used here are supported by all common open-source shells supporting the
local keyword.
Test these new functions as part of t0000, which also serves to
demonstrate basic usage of them. In addition, add documentation on how
to format the lookup data and how to use the test functions.
Implement two basic lookup charts, one for common invalid or synthesized
object IDs, and one for various facts about the hash function in use.
Provide versions of the data for both SHA-1 and SHA-256.
Since we use shell variables for storage, names used for lookup can
currently consist only of shell identifier characters. If this is a
problem in the future, we can hash the names before use.
Improved-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-13 05:17:31 +00:00
|
|
|
}
|
|
|
|
|
2023-12-29 07:26:56 +00:00
|
|
|
# Detect the hash algorithm in use.
|
|
|
|
test_detect_ref_format () {
|
|
|
|
echo "${GIT_TEST_DEFAULT_REF_FORMAT:-files}"
|
|
|
|
}
|
|
|
|
|
t: add test functions to translate hash-related values
Add several test functions to make working with various hash-related
values easier.
Add test_oid_init, which loads common hash-related constants and
placeholder object IDs from the newly added files in t/oid-info.
Provide values for these constants for both SHA-1 and SHA-256.
Add test_oid_cache, which accepts data on standard input in the form of
hash-specific key-value pairs that can be looked up later, using the
same format as the files in t/oid-info. Document this format in a
t/oid-info/README directory so that it's easier to use in the future.
Add test_oid, which is used to specify look up a per-hash value
(produced on standard output) based on the key specified as its
argument. Usually the data to be looked up will be a hash-related
constant (such as the size of the hash in binary or hexadecimal), a
well-known or placeholder object ID (such as the all-zeros object ID or
one consisting of "deadbeef" repeated), or something similar. For these
reasons, test_oid will usually be used within a command substitution.
Consequently, redirect the error output to standard error, since
otherwise it will not be displayed.
Add test_detect_hash, which currently only detects SHA-1, and
test_set_hash, which can be used to set a different hash algorithm for
test purposes. In the future, test_detect_hash will learn to actually
detect the hash depending on how the testsuite is to be run.
Use the local keyword within these functions to avoid overwriting other
shell variables. We have had a test balloon in place for a couple of
releases to catch shells that don't have this keyword and have not
received any reports of failure. Note that the varying usages of local
used here are supported by all common open-source shells supporting the
local keyword.
Test these new functions as part of t0000, which also serves to
demonstrate basic usage of them. In addition, add documentation on how
to format the lookup data and how to use the test functions.
Implement two basic lookup charts, one for common invalid or synthesized
object IDs, and one for various facts about the hash function in use.
Provide versions of the data for both SHA-1 and SHA-256.
Since we use shell variables for storage, names used for lookup can
currently consist only of shell identifier characters. If this is a
problem in the future, we can hash the names before use.
Improved-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-13 05:17:31 +00:00
|
|
|
# Load common hash metadata and common placeholder object IDs for use with
|
|
|
|
# test_oid.
|
|
|
|
test_oid_init () {
|
|
|
|
test -n "$test_hash_algo" || test_detect_hash &&
|
|
|
|
test_oid_cache <"$TEST_DIRECTORY/oid-info/hash-info" &&
|
|
|
|
test_oid_cache <"$TEST_DIRECTORY/oid-info/oid"
|
|
|
|
}
|
|
|
|
|
|
|
|
# Load key-value pairs from stdin suitable for use with test_oid. Blank lines
|
|
|
|
# and lines starting with "#" are ignored. Keys must be shell identifier
|
|
|
|
# characters.
|
|
|
|
#
|
|
|
|
# Examples:
|
|
|
|
# rawsz sha1:20
|
|
|
|
# rawsz sha256:32
|
|
|
|
test_oid_cache () {
|
|
|
|
local tag rest k v &&
|
|
|
|
|
|
|
|
{ test -n "$test_hash_algo" || test_detect_hash; } &&
|
|
|
|
while read tag rest
|
|
|
|
do
|
|
|
|
case $tag in
|
|
|
|
\#*)
|
|
|
|
continue;;
|
|
|
|
?*)
|
|
|
|
# non-empty
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
# blank line
|
|
|
|
continue;;
|
|
|
|
esac &&
|
|
|
|
|
|
|
|
k="${rest%:*}" &&
|
|
|
|
v="${rest#*:}" &&
|
|
|
|
|
|
|
|
if ! expr "$k" : '[a-z0-9][a-z0-9]*$' >/dev/null
|
|
|
|
then
|
tests: send "bug in the test script" errors to the script's stderr
Some of the functions in our test library check that they were invoked
properly with conditions like this:
test "$#" = 2 ||
error "bug in the test script: not 2 parameters to test-expect-success"
If this particular condition is triggered, then 'error' will abort the
whole test script with a bold red error message [1] right away.
However, under certain circumstances the test script will be aborted
completely silently, namely if:
- a similar condition in a test helper function like
'test_line_count' is triggered,
- which is invoked from the test script's "main" shell [2],
- and the test script is run manually (i.e. './t1234-foo.sh' as
opposed to 'make t1234-foo.sh' or 'make test') [3]
- and without the '--verbose' option,
because the error message is printed from within 'test_eval_', where
standard output is redirected either to /dev/null or to a log file.
The only indication that something is wrong is that not all tests in
the script are executed and at the end of the test script's output
there is no "# passed all N tests" message, which are subtle and can
easily go unnoticed, as I had to experience myself.
Send these "bug in the test script" error messages directly to the
test scripts standard error and thus to the terminal, so those bugs
will be much harder to overlook. Instead of updating all ~20 such
'error' calls with a redirection, let's add a BUG() function to
'test-lib.sh', wrapping an 'error' call with the proper redirection
and also including the common prefix of those error messages, and
convert all those call sites [4] to use this new BUG() function
instead.
[1] That particular error message from 'test_expect_success' is
printed in color only when running with or without '--verbose';
with '--tee' or '--verbose-log' the error is printed without
color, but it is printed to the terminal nonetheless.
[2] If such a condition is triggered in a subshell of a test, then
'error' won't be able to abort the whole test script, but only the
subshell, which in turn causes the test to fail in the usual way,
indicating loudly and clearly that something is wrong.
[3] Well, 'error' aborts the test script the same way when run
manually or by 'make' or 'prove', but both 'make' and 'prove' pay
attention to the test script's exit status, and even a silently
aborted test script would then trigger those tools' usual
noticable error messages.
[4] Strictly speaking, not all those 'error' calls need that
redirection to send their output to the terminal, see e.g.
'test_expect_success' in the opening example, but I think it's
better to be consistent.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-19 13:13:26 +00:00
|
|
|
BUG 'bad hash algorithm'
|
t: add test functions to translate hash-related values
Add several test functions to make working with various hash-related
values easier.
Add test_oid_init, which loads common hash-related constants and
placeholder object IDs from the newly added files in t/oid-info.
Provide values for these constants for both SHA-1 and SHA-256.
Add test_oid_cache, which accepts data on standard input in the form of
hash-specific key-value pairs that can be looked up later, using the
same format as the files in t/oid-info. Document this format in a
t/oid-info/README directory so that it's easier to use in the future.
Add test_oid, which is used to specify look up a per-hash value
(produced on standard output) based on the key specified as its
argument. Usually the data to be looked up will be a hash-related
constant (such as the size of the hash in binary or hexadecimal), a
well-known or placeholder object ID (such as the all-zeros object ID or
one consisting of "deadbeef" repeated), or something similar. For these
reasons, test_oid will usually be used within a command substitution.
Consequently, redirect the error output to standard error, since
otherwise it will not be displayed.
Add test_detect_hash, which currently only detects SHA-1, and
test_set_hash, which can be used to set a different hash algorithm for
test purposes. In the future, test_detect_hash will learn to actually
detect the hash depending on how the testsuite is to be run.
Use the local keyword within these functions to avoid overwriting other
shell variables. We have had a test balloon in place for a couple of
releases to catch shells that don't have this keyword and have not
received any reports of failure. Note that the varying usages of local
used here are supported by all common open-source shells supporting the
local keyword.
Test these new functions as part of t0000, which also serves to
demonstrate basic usage of them. In addition, add documentation on how
to format the lookup data and how to use the test functions.
Implement two basic lookup charts, one for common invalid or synthesized
object IDs, and one for various facts about the hash function in use.
Provide versions of the data for both SHA-1 and SHA-256.
Since we use shell variables for storage, names used for lookup can
currently consist only of shell identifier characters. If this is a
problem in the future, we can hash the names before use.
Improved-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-13 05:17:31 +00:00
|
|
|
fi &&
|
|
|
|
eval "test_oid_${k}_$tag=\"\$v\""
|
|
|
|
done
|
|
|
|
}
|
|
|
|
|
|
|
|
# Look up a per-hash value based on a key ($1). The value must have been loaded
|
|
|
|
# by test_oid_init or test_oid_cache.
|
|
|
|
test_oid () {
|
2020-07-29 23:14:23 +00:00
|
|
|
local algo="${test_hash_algo}" &&
|
|
|
|
|
|
|
|
case "$1" in
|
|
|
|
--hash=*)
|
|
|
|
algo="${1#--hash=}" &&
|
|
|
|
shift;;
|
|
|
|
*)
|
|
|
|
;;
|
|
|
|
esac &&
|
|
|
|
|
|
|
|
local var="test_oid_${algo}_$1" &&
|
t: add test functions to translate hash-related values
Add several test functions to make working with various hash-related
values easier.
Add test_oid_init, which loads common hash-related constants and
placeholder object IDs from the newly added files in t/oid-info.
Provide values for these constants for both SHA-1 and SHA-256.
Add test_oid_cache, which accepts data on standard input in the form of
hash-specific key-value pairs that can be looked up later, using the
same format as the files in t/oid-info. Document this format in a
t/oid-info/README directory so that it's easier to use in the future.
Add test_oid, which is used to specify look up a per-hash value
(produced on standard output) based on the key specified as its
argument. Usually the data to be looked up will be a hash-related
constant (such as the size of the hash in binary or hexadecimal), a
well-known or placeholder object ID (such as the all-zeros object ID or
one consisting of "deadbeef" repeated), or something similar. For these
reasons, test_oid will usually be used within a command substitution.
Consequently, redirect the error output to standard error, since
otherwise it will not be displayed.
Add test_detect_hash, which currently only detects SHA-1, and
test_set_hash, which can be used to set a different hash algorithm for
test purposes. In the future, test_detect_hash will learn to actually
detect the hash depending on how the testsuite is to be run.
Use the local keyword within these functions to avoid overwriting other
shell variables. We have had a test balloon in place for a couple of
releases to catch shells that don't have this keyword and have not
received any reports of failure. Note that the varying usages of local
used here are supported by all common open-source shells supporting the
local keyword.
Test these new functions as part of t0000, which also serves to
demonstrate basic usage of them. In addition, add documentation on how
to format the lookup data and how to use the test functions.
Implement two basic lookup charts, one for common invalid or synthesized
object IDs, and one for various facts about the hash function in use.
Provide versions of the data for both SHA-1 and SHA-256.
Since we use shell variables for storage, names used for lookup can
currently consist only of shell identifier characters. If this is a
problem in the future, we can hash the names before use.
Improved-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-13 05:17:31 +00:00
|
|
|
|
|
|
|
# If the variable is unset, we must be missing an entry for this
|
|
|
|
# key-hash pair, so exit with an error.
|
|
|
|
if eval "test -z \"\${$var+set}\""
|
|
|
|
then
|
tests: send "bug in the test script" errors to the script's stderr
Some of the functions in our test library check that they were invoked
properly with conditions like this:
test "$#" = 2 ||
error "bug in the test script: not 2 parameters to test-expect-success"
If this particular condition is triggered, then 'error' will abort the
whole test script with a bold red error message [1] right away.
However, under certain circumstances the test script will be aborted
completely silently, namely if:
- a similar condition in a test helper function like
'test_line_count' is triggered,
- which is invoked from the test script's "main" shell [2],
- and the test script is run manually (i.e. './t1234-foo.sh' as
opposed to 'make t1234-foo.sh' or 'make test') [3]
- and without the '--verbose' option,
because the error message is printed from within 'test_eval_', where
standard output is redirected either to /dev/null or to a log file.
The only indication that something is wrong is that not all tests in
the script are executed and at the end of the test script's output
there is no "# passed all N tests" message, which are subtle and can
easily go unnoticed, as I had to experience myself.
Send these "bug in the test script" error messages directly to the
test scripts standard error and thus to the terminal, so those bugs
will be much harder to overlook. Instead of updating all ~20 such
'error' calls with a redirection, let's add a BUG() function to
'test-lib.sh', wrapping an 'error' call with the proper redirection
and also including the common prefix of those error messages, and
convert all those call sites [4] to use this new BUG() function
instead.
[1] That particular error message from 'test_expect_success' is
printed in color only when running with or without '--verbose';
with '--tee' or '--verbose-log' the error is printed without
color, but it is printed to the terminal nonetheless.
[2] If such a condition is triggered in a subshell of a test, then
'error' won't be able to abort the whole test script, but only the
subshell, which in turn causes the test to fail in the usual way,
indicating loudly and clearly that something is wrong.
[3] Well, 'error' aborts the test script the same way when run
manually or by 'make' or 'prove', but both 'make' and 'prove' pay
attention to the test script's exit status, and even a silently
aborted test script would then trigger those tools' usual
noticable error messages.
[4] Strictly speaking, not all those 'error' calls need that
redirection to send their output to the terminal, see e.g.
'test_expect_success' in the opening example, but I think it's
better to be consistent.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-19 13:13:26 +00:00
|
|
|
BUG "undefined key '$1'"
|
t: add test functions to translate hash-related values
Add several test functions to make working with various hash-related
values easier.
Add test_oid_init, which loads common hash-related constants and
placeholder object IDs from the newly added files in t/oid-info.
Provide values for these constants for both SHA-1 and SHA-256.
Add test_oid_cache, which accepts data on standard input in the form of
hash-specific key-value pairs that can be looked up later, using the
same format as the files in t/oid-info. Document this format in a
t/oid-info/README directory so that it's easier to use in the future.
Add test_oid, which is used to specify look up a per-hash value
(produced on standard output) based on the key specified as its
argument. Usually the data to be looked up will be a hash-related
constant (such as the size of the hash in binary or hexadecimal), a
well-known or placeholder object ID (such as the all-zeros object ID or
one consisting of "deadbeef" repeated), or something similar. For these
reasons, test_oid will usually be used within a command substitution.
Consequently, redirect the error output to standard error, since
otherwise it will not be displayed.
Add test_detect_hash, which currently only detects SHA-1, and
test_set_hash, which can be used to set a different hash algorithm for
test purposes. In the future, test_detect_hash will learn to actually
detect the hash depending on how the testsuite is to be run.
Use the local keyword within these functions to avoid overwriting other
shell variables. We have had a test balloon in place for a couple of
releases to catch shells that don't have this keyword and have not
received any reports of failure. Note that the varying usages of local
used here are supported by all common open-source shells supporting the
local keyword.
Test these new functions as part of t0000, which also serves to
demonstrate basic usage of them. In addition, add documentation on how
to format the lookup data and how to use the test functions.
Implement two basic lookup charts, one for common invalid or synthesized
object IDs, and one for various facts about the hash function in use.
Provide versions of the data for both SHA-1 and SHA-256.
Since we use shell variables for storage, names used for lookup can
currently consist only of shell identifier characters. If this is a
problem in the future, we can hash the names before use.
Improved-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-13 05:17:31 +00:00
|
|
|
fi &&
|
tests: make 'test_oid' print trailing newline
Unlike other test helper functions, 'test_oid' doesn't terminate its
output with a LF, but, alas, the reason for this, if any, is not
mentioned in 2c02b110da (t: add test functions to translate
hash-related values, 2018-09-13)).
Now, in the vast majority of cases 'test_oid' is invoked in a command
substitution that is part of a heredoc or supplies an argument to a
command or the value to a variable, and the command substitution would
chop off any trailing LFs, so in these cases the lack or presence of a
trailing LF in its output doesn't matter. However:
- There appear to be only three cases where 'test_oid' is not
invoked in a command substitution:
$ git grep '\stest_oid ' -- ':/t/*.sh'
t0000-basic.sh: test_oid zero >actual &&
t0000-basic.sh: test_oid zero >actual &&
t0000-basic.sh: test_oid zero >actual &&
These are all in test cases checking that 'test_oid' actually
works, and that the size of its output matches the size of the
corresponding hash function with conditions like
test $(wc -c <actual) -eq 40
In these cases the lack of trailing LF does actually matter,
though they could be trivially updated to account for the presence
of a trailing LF.
- There are also a few cases where the lack of trailing LF in
'test_oid's output actually hurts, because tests need to compare
its output with LF terminated file contents, forcing developers to
invoke it as 'echo $(test_oid ...)' to append the missing LF:
$ git grep 'echo "\?$(test_oid ' -- ':/t/*.sh'
t1302-repo-version.sh: echo $(test_oid version) >expect &&
t1500-rev-parse.sh: echo "$(test_oid algo)" >expect &&
t4044-diff-index-unique-abbrev.sh: echo "$(test_oid val1)" > foo &&
t4044-diff-index-unique-abbrev.sh: echo "$(test_oid val2)" > foo &&
t5313-pack-bounds-checks.sh: echo $(test_oid oidfff) >file &&
And there is yet another similar case in an in-flight topic at:
https://public-inbox.org/git/813e81a058227bd373cec802e443fcd677042fb4.1670862677.git.gitgitgadget@gmail.com/
Arguably we would be better off if 'test_oid' terminated its output
with a LF. So let's update 'test_oid' accordingly, update its tests
in t0000 to account for the extra character in those size tests, and
remove the now unnecessary 'echo $(...)' command substitutions around
'test_oid' invocations as well.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-12-18 16:29:05 +00:00
|
|
|
eval "printf '%s\n' \"\${$var}\""
|
t: add test functions to translate hash-related values
Add several test functions to make working with various hash-related
values easier.
Add test_oid_init, which loads common hash-related constants and
placeholder object IDs from the newly added files in t/oid-info.
Provide values for these constants for both SHA-1 and SHA-256.
Add test_oid_cache, which accepts data on standard input in the form of
hash-specific key-value pairs that can be looked up later, using the
same format as the files in t/oid-info. Document this format in a
t/oid-info/README directory so that it's easier to use in the future.
Add test_oid, which is used to specify look up a per-hash value
(produced on standard output) based on the key specified as its
argument. Usually the data to be looked up will be a hash-related
constant (such as the size of the hash in binary or hexadecimal), a
well-known or placeholder object ID (such as the all-zeros object ID or
one consisting of "deadbeef" repeated), or something similar. For these
reasons, test_oid will usually be used within a command substitution.
Consequently, redirect the error output to standard error, since
otherwise it will not be displayed.
Add test_detect_hash, which currently only detects SHA-1, and
test_set_hash, which can be used to set a different hash algorithm for
test purposes. In the future, test_detect_hash will learn to actually
detect the hash depending on how the testsuite is to be run.
Use the local keyword within these functions to avoid overwriting other
shell variables. We have had a test balloon in place for a couple of
releases to catch shells that don't have this keyword and have not
received any reports of failure. Note that the varying usages of local
used here are supported by all common open-source shells supporting the
local keyword.
Test these new functions as part of t0000, which also serves to
demonstrate basic usage of them. In addition, add documentation on how
to format the lookup data and how to use the test functions.
Implement two basic lookup charts, one for common invalid or synthesized
object IDs, and one for various facts about the hash function in use.
Provide versions of the data for both SHA-1 and SHA-256.
Since we use shell variables for storage, names used for lookup can
currently consist only of shell identifier characters. If this is a
problem in the future, we can hash the names before use.
Improved-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-13 05:17:31 +00:00
|
|
|
}
|
test-lib-functions: introduce the 'test_set_port' helper function
Several test scripts run daemons like 'git-daemon' or Apache, and
communicate with them through TCP sockets. To have unique ports where
these daemons are accessible, the ports are usually the number of the
corresponding test scripts, unless the user overrides them via
environment variables, and thus all those tests and test libs contain
more or less the same bit of one-liner boilerplate code to find out
the port. The last patch in this series will make this a bit more
complicated.
Factor out finding the port for a daemon into the common helper
function 'test_set_port' to avoid repeating ourselves.
Take special care of test scripts with "low" numbers:
- Test numbers below 1024 would result in a port that's only usable
as root, so set their port to '10000 + test-nr' to make sure it
doesn't interfere with other tests in the test suite. This makes
the hardcoded port number in 't0410-partial-clone.sh' unnecessary,
remove it.
- The shell's arithmetic evaluation interprets numbers with leading
zeros as octal values, which means that test number below 1000 and
containing the digits 8 or 9 will trigger an error. Remove all
leading zeros from the test numbers to prevent this.
Note that the 'git p4' tests are unlike the other tests involving
daemons in that:
- 'lib-git-p4.sh' doesn't use the test's number for unique port as
is, but does a bit of additional arithmetic on top [1].
- The port is not overridable via an environment variable.
With this patch even 'git p4' tests will use the test's number as
default port, and it will be overridable via the P4DPORT environment
variable.
[1] Commit fc00233071 (git-p4 tests: refactor and cleanup, 2011-08-22)
introduced that "unusual" unique port computation without
explaining why it was necessary (as opposed to simply using the
test number as is). It seems to be just unnecessary complication,
and in any case that commit came way before the "test nr as unique
port" got "standardized" for other daemons in commits c44132fcf3
(tests: auto-set git-daemon port, 2014-02-10), 3bb486e439 (tests:
auto-set LIB_HTTPD_PORT from test name, 2014-02-10), and
bf9d7df950 (t/lib-git-svn.sh: improve svnserve tests with parallel
make test, 2017-12-01).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-05 01:08:58 +00:00
|
|
|
|
2019-06-28 22:59:19 +00:00
|
|
|
# Insert a slash into an object ID so it can be used to reference a location
|
|
|
|
# under ".git/objects". For example, "deadbeef..." becomes "de/adbeef..".
|
|
|
|
test_oid_to_path () {
|
2019-08-08 06:56:14 +00:00
|
|
|
local basename=${1#??}
|
|
|
|
echo "${1%$basename}/$basename"
|
2019-06-28 22:59:19 +00:00
|
|
|
}
|
|
|
|
|
2022-04-05 05:20:15 +00:00
|
|
|
# Parse oids from git ls-files --staged output
|
|
|
|
test_parse_ls_files_stage_oids () {
|
|
|
|
awk '{print $2}' -
|
|
|
|
}
|
|
|
|
|
|
|
|
# Parse oids from git ls-tree output
|
|
|
|
test_parse_ls_tree_oids () {
|
|
|
|
awk '{print $3}' -
|
|
|
|
}
|
|
|
|
|
test-lib-functions: introduce the 'test_set_port' helper function
Several test scripts run daemons like 'git-daemon' or Apache, and
communicate with them through TCP sockets. To have unique ports where
these daemons are accessible, the ports are usually the number of the
corresponding test scripts, unless the user overrides them via
environment variables, and thus all those tests and test libs contain
more or less the same bit of one-liner boilerplate code to find out
the port. The last patch in this series will make this a bit more
complicated.
Factor out finding the port for a daemon into the common helper
function 'test_set_port' to avoid repeating ourselves.
Take special care of test scripts with "low" numbers:
- Test numbers below 1024 would result in a port that's only usable
as root, so set their port to '10000 + test-nr' to make sure it
doesn't interfere with other tests in the test suite. This makes
the hardcoded port number in 't0410-partial-clone.sh' unnecessary,
remove it.
- The shell's arithmetic evaluation interprets numbers with leading
zeros as octal values, which means that test number below 1000 and
containing the digits 8 or 9 will trigger an error. Remove all
leading zeros from the test numbers to prevent this.
Note that the 'git p4' tests are unlike the other tests involving
daemons in that:
- 'lib-git-p4.sh' doesn't use the test's number for unique port as
is, but does a bit of additional arithmetic on top [1].
- The port is not overridable via an environment variable.
With this patch even 'git p4' tests will use the test's number as
default port, and it will be overridable via the P4DPORT environment
variable.
[1] Commit fc00233071 (git-p4 tests: refactor and cleanup, 2011-08-22)
introduced that "unusual" unique port computation without
explaining why it was necessary (as opposed to simply using the
test number as is). It seems to be just unnecessary complication,
and in any case that commit came way before the "test nr as unique
port" got "standardized" for other daemons in commits c44132fcf3
(tests: auto-set git-daemon port, 2014-02-10), 3bb486e439 (tests:
auto-set LIB_HTTPD_PORT from test name, 2014-02-10), and
bf9d7df950 (t/lib-git-svn.sh: improve svnserve tests with parallel
make test, 2017-12-01).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-05 01:08:58 +00:00
|
|
|
# Choose a port number based on the test script's number and store it in
|
|
|
|
# the given variable name, unless that variable already contains a number.
|
|
|
|
test_set_port () {
|
|
|
|
local var=$1 port
|
|
|
|
|
|
|
|
if test $# -ne 1 || test -z "$var"
|
|
|
|
then
|
|
|
|
BUG "test_set_port requires a variable name"
|
|
|
|
fi
|
|
|
|
|
|
|
|
eval port=\$$var
|
|
|
|
case "$port" in
|
|
|
|
"")
|
|
|
|
# No port is set in the given env var, use the test
|
|
|
|
# number as port number instead.
|
|
|
|
# Remove not only the leading 't', but all leading zeros
|
|
|
|
# as well, so the arithmetic below won't (mis)interpret
|
|
|
|
# a test number like '0123' as an octal value.
|
|
|
|
port=${this_test#${this_test%%[1-9]*}}
|
|
|
|
if test "${port:-0}" -lt 1024
|
|
|
|
then
|
|
|
|
# root-only port, use a larger one instead.
|
|
|
|
port=$(($port + 10000))
|
|
|
|
fi
|
|
|
|
;;
|
2019-02-11 19:58:03 +00:00
|
|
|
*[!0-9]*|0*)
|
test-lib-functions: introduce the 'test_set_port' helper function
Several test scripts run daemons like 'git-daemon' or Apache, and
communicate with them through TCP sockets. To have unique ports where
these daemons are accessible, the ports are usually the number of the
corresponding test scripts, unless the user overrides them via
environment variables, and thus all those tests and test libs contain
more or less the same bit of one-liner boilerplate code to find out
the port. The last patch in this series will make this a bit more
complicated.
Factor out finding the port for a daemon into the common helper
function 'test_set_port' to avoid repeating ourselves.
Take special care of test scripts with "low" numbers:
- Test numbers below 1024 would result in a port that's only usable
as root, so set their port to '10000 + test-nr' to make sure it
doesn't interfere with other tests in the test suite. This makes
the hardcoded port number in 't0410-partial-clone.sh' unnecessary,
remove it.
- The shell's arithmetic evaluation interprets numbers with leading
zeros as octal values, which means that test number below 1000 and
containing the digits 8 or 9 will trigger an error. Remove all
leading zeros from the test numbers to prevent this.
Note that the 'git p4' tests are unlike the other tests involving
daemons in that:
- 'lib-git-p4.sh' doesn't use the test's number for unique port as
is, but does a bit of additional arithmetic on top [1].
- The port is not overridable via an environment variable.
With this patch even 'git p4' tests will use the test's number as
default port, and it will be overridable via the P4DPORT environment
variable.
[1] Commit fc00233071 (git-p4 tests: refactor and cleanup, 2011-08-22)
introduced that "unusual" unique port computation without
explaining why it was necessary (as opposed to simply using the
test number as is). It seems to be just unnecessary complication,
and in any case that commit came way before the "test nr as unique
port" got "standardized" for other daemons in commits c44132fcf3
(tests: auto-set git-daemon port, 2014-02-10), 3bb486e439 (tests:
auto-set LIB_HTTPD_PORT from test name, 2014-02-10), and
bf9d7df950 (t/lib-git-svn.sh: improve svnserve tests with parallel
make test, 2017-12-01).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-05 01:08:58 +00:00
|
|
|
error >&7 "invalid port number: $port"
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
# The user has specified the port.
|
|
|
|
;;
|
|
|
|
esac
|
test-lib: add the '--stress' option to run a test repeatedly under load
Unfortunately, we have a few flaky tests, whose failures tend to be
hard to reproduce. We've found that the best we can do to reproduce
such a failure is to run the test script repeatedly while the machine
is under load, and wait in the hope that the load creates enough
variance in the timing of the test's commands that a failure is
evenually triggered. I have a command to do that, and I noticed that
two other contributors have rolled their own scripts to do the same,
all choosing slightly different approaches.
To help reproduce failures in flaky tests, introduce the '--stress'
option to run a test script repeatedly in multiple parallel jobs until
one of them fails, thereby using the test script itself to increase
the load on the machine.
The number of parallel jobs is determined by, in order of precedence:
the number specified as '--stress=<N>', or the value of the
GIT_TEST_STRESS_LOAD environment variable, or twice the number of
available processors (as reported by the 'getconf' utility), or 8.
Make '--stress' imply '--verbose -x --immediate' to get the most
information about rare failures; there is really no point in spending
all the extra effort to reproduce such a failure, and then not know
which command failed and why.
To prevent the several parallel invocations of the same test from
interfering with each other:
- Include the parallel job's number in the name of the trash
directory and the various output files under 't/test-results/' as
a '.stress-<Nr>' suffix.
- Add the parallel job's number to the port number specified by the
user or to the test number, so even tests involving daemons
listening on a TCP socket can be stressed.
- Redirect each parallel test run's verbose output to
't/test-results/$TEST_NAME.stress-<nr>.out', because dumping the
output of several parallel running tests to the terminal would
create a big ugly mess.
For convenience, print the output of the failed test job at the end,
and rename its trash directory to end with the '.stress-failed'
suffix, so it's easy to find in a predictable path (OTOH, all absolute
paths recorded in the trash directory become invalid; we'll see
whether this causes any issues in practice). If, in an unlikely case,
more than one jobs were to fail nearly at the same time, then print
the output of all failed jobs, and rename the trash directory of only
the last one (i.e. with the highest job number), as it is the trash
directory of the test whose output will be at the bottom of the user's
terminal.
Based on Jeff King's 'stress' script.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-05 01:08:59 +00:00
|
|
|
|
|
|
|
# Make sure that parallel '--stress' test jobs get different
|
|
|
|
# ports.
|
|
|
|
port=$(($port + ${GIT_TEST_STRESS_JOB_NR:-0}))
|
|
|
|
eval $var=$port
|
test-lib-functions: introduce the 'test_set_port' helper function
Several test scripts run daemons like 'git-daemon' or Apache, and
communicate with them through TCP sockets. To have unique ports where
these daemons are accessible, the ports are usually the number of the
corresponding test scripts, unless the user overrides them via
environment variables, and thus all those tests and test libs contain
more or less the same bit of one-liner boilerplate code to find out
the port. The last patch in this series will make this a bit more
complicated.
Factor out finding the port for a daemon into the common helper
function 'test_set_port' to avoid repeating ourselves.
Take special care of test scripts with "low" numbers:
- Test numbers below 1024 would result in a port that's only usable
as root, so set their port to '10000 + test-nr' to make sure it
doesn't interfere with other tests in the test suite. This makes
the hardcoded port number in 't0410-partial-clone.sh' unnecessary,
remove it.
- The shell's arithmetic evaluation interprets numbers with leading
zeros as octal values, which means that test number below 1000 and
containing the digits 8 or 9 will trigger an error. Remove all
leading zeros from the test numbers to prevent this.
Note that the 'git p4' tests are unlike the other tests involving
daemons in that:
- 'lib-git-p4.sh' doesn't use the test's number for unique port as
is, but does a bit of additional arithmetic on top [1].
- The port is not overridable via an environment variable.
With this patch even 'git p4' tests will use the test's number as
default port, and it will be overridable via the P4DPORT environment
variable.
[1] Commit fc00233071 (git-p4 tests: refactor and cleanup, 2011-08-22)
introduced that "unusual" unique port computation without
explaining why it was necessary (as opposed to simply using the
test number as is). It seems to be just unnecessary complication,
and in any case that commit came way before the "test nr as unique
port" got "standardized" for other daemons in commits c44132fcf3
(tests: auto-set git-daemon port, 2014-02-10), 3bb486e439 (tests:
auto-set LIB_HTTPD_PORT from test name, 2014-02-10), and
bf9d7df950 (t/lib-git-svn.sh: improve svnserve tests with parallel
make test, 2017-12-01).
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-05 01:08:58 +00:00
|
|
|
}
|
2020-02-14 18:22:25 +00:00
|
|
|
|
2020-04-11 13:40:22 +00:00
|
|
|
# Tests for the hidden file attribute on Windows
|
|
|
|
test_path_is_hidden () {
|
|
|
|
test_have_prereq MINGW ||
|
|
|
|
BUG "test_path_is_hidden can only be used on Windows"
|
|
|
|
|
2020-04-11 13:40:20 +00:00
|
|
|
# Use the output of `attrib`, ignore the absolute path
|
2020-04-11 13:40:21 +00:00
|
|
|
case "$("$SYSTEMROOT"/system32/attrib "$1")" in *H*?:*) return 0;; esac
|
2020-04-11 13:40:20 +00:00
|
|
|
return 1
|
|
|
|
}
|
maintenance: create basic maintenance runner
The 'gc' builtin is our current entrypoint for automatically maintaining
a repository. This one tool does many operations, such as repacking the
repository, packing refs, and rewriting the commit-graph file. The name
implies it performs "garbage collection" which means several different
things, and some users may not want to use this operation that rewrites
the entire object database.
Create a new 'maintenance' builtin that will become a more general-
purpose command. To start, it will only support the 'run' subcommand,
but will later expand to add subcommands for scheduling maintenance in
the background.
For now, the 'maintenance' builtin is a thin shim over the 'gc' builtin.
In fact, the only option is the '--auto' toggle, which is handed
directly to the 'gc' builtin. The current change is isolated to this
simple operation to prevent more interesting logic from being lost in
all of the boilerplate of adding a new builtin.
Use existing builtin/gc.c file because we want to share code between the
two builtins. It is possible that we will have 'maintenance' replace the
'gc' builtin entirely at some point, leaving 'git gc' as an alias for
some specific arguments to 'git maintenance run'.
Create a new test_subcommand helper that allows us to test if a certain
subcommand was run. It requires storing the GIT_TRACE2_EVENT logs in a
file. A negation mode is available that will be used in later tests.
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-17 18:11:42 +00:00
|
|
|
|
2022-12-22 15:14:08 +00:00
|
|
|
# Poor man's URI escaping. Good enough for the test suite whose trash
|
|
|
|
# directory has a space in it. See 93c3fcbe4d4 (git-svn: attempt to
|
|
|
|
# mimic SVN 1.7 URL canonicalization, 2012-07-28) for prior art.
|
|
|
|
test_uri_escape() {
|
|
|
|
sed 's/ /%20/g'
|
|
|
|
}
|
|
|
|
|
maintenance: create basic maintenance runner
The 'gc' builtin is our current entrypoint for automatically maintaining
a repository. This one tool does many operations, such as repacking the
repository, packing refs, and rewriting the commit-graph file. The name
implies it performs "garbage collection" which means several different
things, and some users may not want to use this operation that rewrites
the entire object database.
Create a new 'maintenance' builtin that will become a more general-
purpose command. To start, it will only support the 'run' subcommand,
but will later expand to add subcommands for scheduling maintenance in
the background.
For now, the 'maintenance' builtin is a thin shim over the 'gc' builtin.
In fact, the only option is the '--auto' toggle, which is handed
directly to the 'gc' builtin. The current change is isolated to this
simple operation to prevent more interesting logic from being lost in
all of the boilerplate of adding a new builtin.
Use existing builtin/gc.c file because we want to share code between the
two builtins. It is possible that we will have 'maintenance' replace the
'gc' builtin entirely at some point, leaving 'git gc' as an alias for
some specific arguments to 'git maintenance run'.
Create a new test_subcommand helper that allows us to test if a certain
subcommand was run. It requires storing the GIT_TRACE2_EVENT logs in a
file. A negation mode is available that will be used in later tests.
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-17 18:11:42 +00:00
|
|
|
# Check that the given command was invoked as part of the
|
|
|
|
# trace2-format trace on stdin.
|
|
|
|
#
|
|
|
|
# test_subcommand [!] <command> <args>... < <trace>
|
|
|
|
#
|
|
|
|
# For example, to look for an invocation of "git upload-pack
|
|
|
|
# /path/to/repo"
|
|
|
|
#
|
|
|
|
# GIT_TRACE2_EVENT=event.log git fetch ... &&
|
|
|
|
# test_subcommand git upload-pack "$PATH" <event.log
|
|
|
|
#
|
|
|
|
# If the first parameter passed is !, this instead checks that
|
|
|
|
# the given command was not called.
|
|
|
|
#
|
|
|
|
test_subcommand () {
|
|
|
|
local negate=
|
|
|
|
if test "$1" = "!"
|
|
|
|
then
|
|
|
|
negate=t
|
|
|
|
shift
|
|
|
|
fi
|
|
|
|
|
|
|
|
local expr=$(printf '"%s",' "$@")
|
|
|
|
expr="${expr%,}"
|
|
|
|
|
|
|
|
if test -n "$negate"
|
|
|
|
then
|
|
|
|
! grep "\[$expr\]"
|
|
|
|
else
|
|
|
|
grep "\[$expr\]"
|
|
|
|
fi
|
|
|
|
}
|
2021-01-23 21:07:08 +00:00
|
|
|
|
|
|
|
# Check that the given command was invoked as part of the
|
|
|
|
# trace2-format trace on stdin.
|
|
|
|
#
|
|
|
|
# test_region [!] <category> <label> git <command> <args>...
|
|
|
|
#
|
|
|
|
# For example, to look for trace2_region_enter("index", "do_read_index", repo)
|
|
|
|
# in an invocation of "git checkout HEAD~1", run
|
|
|
|
#
|
|
|
|
# GIT_TRACE2_EVENT="$(pwd)/trace.txt" GIT_TRACE2_EVENT_NESTING=10 \
|
|
|
|
# git checkout HEAD~1 &&
|
|
|
|
# test_region index do_read_index <trace.txt
|
|
|
|
#
|
|
|
|
# If the first parameter passed is !, this instead checks that
|
|
|
|
# the given region was not entered.
|
|
|
|
#
|
|
|
|
test_region () {
|
|
|
|
local expect_exit=0
|
|
|
|
if test "$1" = "!"
|
|
|
|
then
|
|
|
|
expect_exit=1
|
|
|
|
shift
|
|
|
|
fi
|
|
|
|
|
|
|
|
grep -e '"region_enter".*"category":"'"$1"'","label":"'"$2"\" "$3"
|
|
|
|
exitcode=$?
|
|
|
|
|
|
|
|
if test $exitcode != $expect_exit
|
|
|
|
then
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
grep -e '"region_leave".*"category":"'"$1"'","label":"'"$2"\" "$3"
|
|
|
|
exitcode=$?
|
|
|
|
|
|
|
|
if test $exitcode != $expect_exit
|
|
|
|
then
|
|
|
|
return 1
|
|
|
|
fi
|
|
|
|
|
|
|
|
return 0
|
|
|
|
}
|
2021-06-18 16:32:22 +00:00
|
|
|
|
2023-12-14 22:24:39 +00:00
|
|
|
# Check that the given data fragment was included as part of the
|
|
|
|
# trace2-format trace on stdin.
|
|
|
|
#
|
|
|
|
# test_trace2_data <category> <key> <value>
|
|
|
|
#
|
|
|
|
# For example, to look for trace2_data_intmax("pack-objects", repo,
|
|
|
|
# "reused", N) in an invocation of "git pack-objects", run:
|
|
|
|
#
|
|
|
|
# GIT_TRACE2_EVENT="$(pwd)/trace.txt" git pack-objects ... &&
|
|
|
|
# test_trace2_data pack-objects reused N <trace2.txt
|
|
|
|
test_trace2_data () {
|
|
|
|
grep -e '"category":"'"$1"'","key":"'"$2"'","value":"'"$3"'"'
|
|
|
|
}
|
|
|
|
|
2023-01-31 13:29:11 +00:00
|
|
|
# Given a GIT_TRACE2_EVENT log over stdin, writes to stdout a list of URLs
|
|
|
|
# sent to git-remote-https child processes.
|
|
|
|
test_remote_https_urls() {
|
|
|
|
grep -e '"event":"child_start".*"argv":\["git-remote-https",".*"\]' |
|
|
|
|
sed -e 's/{"event":"child_start".*"argv":\["git-remote-https","//g' \
|
|
|
|
-e 's/"\]}//g'
|
|
|
|
}
|
|
|
|
|
2021-06-18 16:32:22 +00:00
|
|
|
# Print the destination of symlink(s) provided as arguments. Basically
|
|
|
|
# the same as the readlink command, but it's not available everywhere.
|
|
|
|
test_readlink () {
|
|
|
|
perl -le 'print readlink($_) for @ARGV' "$@"
|
|
|
|
}
|
2022-01-07 11:17:28 +00:00
|
|
|
|
|
|
|
# Set mtime to a fixed "magic" timestamp in mid February 2009, before we
|
|
|
|
# run an operation that may or may not touch the file. If the file was
|
|
|
|
# touched, its timestamp will not accidentally have such an old timestamp,
|
|
|
|
# as long as your filesystem clock is reasonably correct. To verify the
|
|
|
|
# timestamp, follow up with test_is_magic_mtime.
|
|
|
|
#
|
|
|
|
# An optional increment to the magic timestamp may be specified as second
|
|
|
|
# argument.
|
|
|
|
test_set_magic_mtime () {
|
|
|
|
local inc=${2:-0} &&
|
|
|
|
local mtime=$((1234567890 + $inc)) &&
|
|
|
|
test-tool chmtime =$mtime "$1" &&
|
|
|
|
test_is_magic_mtime "$1" $inc
|
|
|
|
}
|
|
|
|
|
|
|
|
# Test whether the given file has the "magic" mtime set. This is meant to
|
|
|
|
# be used in combination with test_set_magic_mtime.
|
|
|
|
#
|
|
|
|
# An optional increment to the magic timestamp may be specified as second
|
|
|
|
# argument. Usually, this should be the same increment which was used for
|
|
|
|
# the associated test_set_magic_mtime.
|
|
|
|
test_is_magic_mtime () {
|
|
|
|
local inc=${2:-0} &&
|
|
|
|
local mtime=$((1234567890 + $inc)) &&
|
|
|
|
echo $mtime >.git/test-mtime-expect &&
|
|
|
|
test-tool chmtime --get "$1" >.git/test-mtime-actual &&
|
|
|
|
test_cmp .git/test-mtime-expect .git/test-mtime-actual
|
|
|
|
local ret=$?
|
|
|
|
rm -f .git/test-mtime-expect
|
|
|
|
rm -f .git/test-mtime-actual
|
|
|
|
return $ret
|
|
|
|
}
|
2022-10-12 12:52:32 +00:00
|
|
|
|
|
|
|
# Given two filenames, parse both using 'git config --list --file'
|
|
|
|
# and compare the sorted output of those commands. Useful when
|
|
|
|
# wanting to ignore whitespace differences and sorting concerns.
|
|
|
|
test_cmp_config_output () {
|
|
|
|
git config --list --file="$1" >config-expect &&
|
|
|
|
git config --list --file="$2" >config-actual &&
|
|
|
|
sort config-expect >sorted-expect &&
|
|
|
|
sort config-actual >sorted-actual &&
|
|
|
|
test_cmp sorted-expect sorted-actual
|
|
|
|
}
|
2023-01-06 16:31:55 +00:00
|
|
|
|
|
|
|
# Given a filename, extract its trailing hash as a hex string
|
|
|
|
test_trailing_hash () {
|
|
|
|
local file="$1" &&
|
|
|
|
tail -c $(test_oid rawsz) "$file" |
|
|
|
|
test-tool hexdump |
|
|
|
|
sed "s/ //g"
|
|
|
|
}
|