summaryrefslogtreecommitdiff
path: root/t/test-lib-functions.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-01-25Merge branch 'ab/mailmap-fixup'Libravatar Junio C Hamano1-2/+2
Follow-up fixes and improvements to ab/mailmap topic. * ab/mailmap-fixup: t4203: make blame output massaging more robust mailmap doc: use correct environment variable 'GIT_WORK_TREE' t4203: stop losing return codes of git commands test-lib-functions.sh: fix usage for test_commit()
2021-01-25Merge branch 'ab/mailmap'Libravatar Junio C Hamano1-7/+30
Clean-up docs, codepaths and tests around mailmap. * ab/mailmap: (22 commits) shortlog: remove unused(?) "repo-abbrev" feature mailmap doc + tests: document and test for case-insensitivity mailmap tests: add tests for empty "<>" syntax mailmap tests: add tests for whitespace syntax mailmap tests: add a test for comment syntax mailmap doc + tests: add better examples & test them tests: refactor a few tests to use "test_commit --append" test-lib functions: add an --append option to test_commit test-lib functions: add --author support to test_commit test-lib functions: document arguments to test_commit test-lib functions: expand "test_commit" comment template mailmap: test for silent exiting on missing file/blob mailmap tests: get rid of overly complex blame fuzzing mailmap tests: add a test for "not a blob" error mailmap tests: remove redundant entry in test mailmap tests: improve --stdin tests mailmap tests: modernize syntax & test idioms mailmap tests: use our preferred whitespace syntax mailmap doc: start by mentioning the comment syntax check-mailmap doc: note config options ...
2021-01-14test-lib-functions.sh: fix usage for test_commit()Libravatar Denton Liu1-2/+2
The usage comment for test_commit() shows that the --author option should be given as `--author=<author>`. However, this is incorrect as it only works when given as `--author <author>`. Correct this erroneous text. Also, for the sake of correctness, fix the description as well since we invoke `git commit` with `--author <author>`, not `--author=<author>`. Signed-off-by: Denton Liu <liu.denton@gmail.com> Acked-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-12test-lib functions: add an --append option to test_commitLibravatar Ævar Arnfjörð Bjarmason1-1/+13
Add an --append option to test_commit to append <contents> to the <file> we're writing to. This simplifies a lot of test setup, as shown in some of the tests being changed here. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-12test-lib functions: add --author support to test_commitLibravatar Ævar Arnfjörð Bjarmason1-1/+10
Add support for --author to "test_commit". This will simplify some current and future tests, one of those is being changed here. Let's also line-wrap the "git commit" command invocation to make diffs that add subsequent options easier to add, as they'll only need to add a new option line. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-12test-lib functions: document arguments to test_commitLibravatar Ævar Arnfjörð Bjarmason1-0/+4
The --notick argument was added in [1] and was followed by --signoff in [2], but neither of these commits added any documentation for these options. When -C was added in [3] a comment was added to document it, but not the other options. Let's document all of these options. 1. 44b85e89d7 (t7003: add test to filter a branch with a commit at epoch, 2012-07-12), 2. 5ed75e2a3f (cherry-pick: don't forget -s on failure, 2012-09-14). 3. 6f94351b0a (test-lib-functions.sh: teach test_commit -C <dir>, 2016-12-08) Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-12test-lib functions: expand "test_commit" comment templateLibravatar Ævar Arnfjörð Bjarmason1-5/+3
Expand the comment template for "test_commit" to match that of "test_commit_bulk" added in b1c36cb849 (test-lib: introduce test_commit_bulk, 2019-07-02). It has several undocumented options, which won't all fit on one line. Follow-up commit(s) will document them. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-06t4129: don't fail if setgid is set in the test directoryLibravatar Matheus Tavares1-2/+7
The last test of t4129 creates a directory and expects its setgid bit (g+s) to be off. But this makes the test fail when the parent directory has the bit set, as setgid's state is inherited by newly created subdirectories. One way to solve this problem is to allow the presence of this bit when comparing the return of `test_modebits` with the expected value. But then we may have the same problem in the future when other tests start using `test_modebits` on directories (currently t4129 is the only one) and forget about setgid. Instead, let's make the helper function more robust with respect to the state of the setgid bit in the test directory by removing this bit from the returning value. There should be no problem with existing callers as no one currently expects this bit to be on. Note that the sticky bit (+t) and the setuid bit (u+s) are not inherited, so we don't have to worry about those. Reported-by: Kevin Daudt <me@ikke.info> Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-18Merge branch 'js/init-defaultbranch-advice'Libravatar Junio C Hamano1-1/+3
Our users are going to be trained to prepare for future change of init.defaultBranch configuration variable. * js/init-defaultbranch-advice: init: provide useful advice about init.defaultBranch get_default_branch_name(): prepare for showing some advice branch -m: allow renaming a yet-unborn branch init: document `init.defaultBranch` better
2020-12-13init: provide useful advice about init.defaultBranchLibravatar Johannes Schindelin1-1/+3
To give ample warning for users wishing to override Git's the fall-back for an unconfigured `init.defaultBranch` (in case we decide to change it in a future Git version), let's introduce some advice that is shown upon `git init` when that value is not set. Note: two test cases in Git's test suite want to verify that the `stderr` output of `git init` is empty. It is now necessary to suppress the advice, we now do that via the `init.defaultBranch` setting. While not strictly necessary, we also set this to `false` in `test_create_repo()`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-08Merge branch 'fc/random-cleanup'Libravatar Junio C Hamano1-4/+4
Random cleanup. * fc/random-cleanup: gitignore: remove entry for git serve gitignore: drop duplicate entry for git-sh-i18n tests: lib-functions: trivial style cleanups test: completion: fix typos .gitignore: remove dangling file refspec: trivial cleanup
2020-12-08Merge branch 'mt/do-not-use-scld-in-working-tree'Libravatar Junio C Hamano1-2/+2
"git apply" adjusted the permission bits of working-tree files and directories according core.sharedRepository setting by mistake and for a long time, which has been corrected. * mt/do-not-use-scld-in-working-tree: apply: don't use core.sharedRepository to create working tree files
2020-12-02apply: don't use core.sharedRepository to create working tree filesLibravatar Matheus Tavares1-2/+2
core.sharedRepository defines which permissions Git should set when creating files in $GIT_DIR, so that the repository may be shared with other users. But (in its current form) the setting shouldn't affect how files are created in the working tree. This is not respected by apply and am (which uses apply), when creating leading directories: $ cat d.patch diff --git a/d/f b/d/f new file mode 100644 index 0000000..e69de29 Apply without the setting: $ umask 0077 $ git apply d.patch $ ls -ld d drwx------ Apply with the setting: $ umask 0077 $ git -c core.sharedRepository=0770 apply d.patch $ ls -ld d drwxrws--- Only the leading directories are affected. That's because they are created with safe_create_leading_directories(), which calls adjust_shared_perm() to set the directories' permissions based on core.sharedRepository. To fix that, let's introduce a variant of this function that ignores the setting, and use it in apply. Also add a regression test and a note in the function documentation about the use of each variant according to the destination (working tree or git dir). Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-01tests: lib-functions: trivial style cleanupsLibravatar Felipe Contreras1-4/+4
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25Merge branch 'sg/tests-prereq'Libravatar Junio C Hamano1-4/+4
A lazily defined test prerequisite can now be defined in terms of another lazily defined test prerequisite. * sg/tests-prereq: tests: fix description of 'test_set_prereq' tests: make sure nested lazy prereqs work reliably
2020-11-18tests: fix description of 'test_set_prereq'Libravatar SZEDER Gábor1-1/+1
'test_set_prereq's description claims that prereqs can be specified to 'test_expect_code', but that is not the case (it is not meant to run a test _case_, but a git command), so remove it. OTOH that description doesn't mention 'test_external' and 'test_external_without_stderr' that do accept prereqs, so mention them. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-18tests: make sure nested lazy prereqs work reliablyLibravatar SZEDER Gábor1-3/+3
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-11Merge branch 'js/test-file-size'Libravatar Junio C Hamano1-0/+4
Test clean-up. * js/test-file-size: tests: consolidate the `file_size` function into `test-lib-functions.sh`
2020-11-06tests: consolidate the `file_size` function into `test-lib-functions.sh`Libravatar Johannes Schindelin1-0/+4
In 8de7eeb54b6 (compression: unify pack.compression configuration parsing, 2016-11-15), we introduced identical copies of the `file_size` helper into three test scripts, with the plan to eventually consolidate them into a single copy. Let's do that, and adjust the function name to adhere to the `test_*` naming convention. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-02Merge branch 'es/test-cmp-typocatcher'Libravatar Junio C Hamano1-14/+2
A test helper "test_cmp A B" was taught to diagnose missing files A or B as a bug in test, but some tests legitimately wanted to notice a failure to even create file B as an error, in addition to leaving the expected result in it, and were misdiagnosed as a bug. This has been corrected. * es/test-cmp-typocatcher: Revert "test_cmp: diagnose incorrect arguments"
2020-10-20Revert "test_cmp: diagnose incorrect arguments"Libravatar Junio C Hamano1-14/+2
This reverts commit d572f52a64c6a69990f72ad6a09504b9b615d2e4; the idea to detect that "test_cmp expect actual" was fed a misspelt filename meant well, but when the version of Git tested exhibits a bug, the reason why these two files do not match may be because one of them did not get created as expected, in which case missing file is not a sign of misspelt filename but is a genuine test failure. Acked-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-25Merge branch 'ds/maintenance-part-1'Libravatar Junio C Hamano1-0/+33
A "git gc"'s big brother has been introduced to take care of more repository maintenance tasks, not limited to the object database cleaning. * ds/maintenance-part-1: maintenance: add trace2 regions for task execution maintenance: add auto condition for commit-graph task maintenance: use pointers to check --auto maintenance: create maintenance.<task>.enabled config maintenance: take a lock on the objects directory maintenance: add --task option maintenance: add commit-graph task maintenance: initialize task array maintenance: replace run_auto_gc() maintenance: add --quiet option maintenance: create basic maintenance runner
2020-09-17maintenance: create basic maintenance runnerLibravatar Derrick Stolee1-0/+33
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-03Merge branch 'jk/slimmed-down'Libravatar Junio C Hamano1-1/+1
Trim an unused binary and turn a bunch of commands into built-in. * jk/slimmed-down: drop vcs-svn experiment make git-fast-import a builtin make git-bugreport a builtin make credential helpers builtins Makefile: drop builtins from MSVC pdb list
2020-08-17Merge branch 'es/test-cmp-typocatcher'Libravatar Junio C Hamano1-2/+14
Test framework update. * es/test-cmp-typocatcher: test_cmp: diagnose incorrect arguments
2020-08-13drop vcs-svn experimentLibravatar Jeff King1-1/+1
The code in vcs-svn was started in 2010 as an attempt to build a remote-helper for interacting with svn repositories (as opposed to git-svn). However, we never got as far as shipping a mature remote helper, and the last substantive commit was e99d012a6bc in 2012. We do have a git-remote-testsvn, and it is even installed as part of "make install". But given the name, it seems unlikely to be used by anybody (you'd have to explicitly "git clone testsvn::$url", and there have been zero mentions of that on the mailing list since 2013, and even that includes the phrase "you might need to hack a bit to get it working properly"[1]). We also ship contrib/svn-fe, which builds on the vcs-svn work. However, it does not seem to build out of the box for me, as the link step misses some required libraries for using libgit.a. Curiously, the original build breakage bisects for me to eff80a9fd9 (Allow custom "comment char", 2013-01-16), which seems unrelated. There was an attempt to fix it in da011cb0e7 (contrib/svn-fe: fix Makefile, 2014-08-28), but on my system that only switches the error message. So it seems like the result is not really usable by anybody in practice. It would be wonderful if somebody wanted to pick up the topic again, and potentially it's worth carrying around for that reason. But the flip side is that people doing tree-wide operations have to deal with this code. And you can see the list with (replace "HEAD" with this commit as appropriate): { echo "--" git diff-tree --diff-filter=D -r --name-only HEAD^ HEAD } | git log --no-merges --oneline e99d012a6bc.. --stdin which shows 58 times somebody had to deal with the code, generally due to a compile or test failure, or a tree-wide style fix or API change. Let's drop it and let anybody who wants to pick it up do so by resurrecting it from the git history. As a bonus, this also reduces the size of a stripped installation of Git from 21MB to 19MB. [1] https://lore.kernel.org/git/CALkWK0mPHzKfzFKKpZkfAus3YVC9NFYDbFnt+5JQYVKipk3bQQ@mail.gmail.com/ Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-11Merge branch 'bc/sha-256-part-3'Libravatar Junio C Hamano1-4/+12
The final leg of SHA-256 transition. * bc/sha-256-part-3: (39 commits) t: remove test_oid_init in tests docs: add documentation for extensions.objectFormat ci: run tests with SHA-256 t: make SHA1 prerequisite depend on default hash t: allow testing different hash algorithms via environment t: add test_oid option to select hash algorithm repository: enable SHA-256 support by default setup: add support for reading extensions.objectformat bundle: add new version for use with SHA-256 builtin/verify-pack: implement an --object-format option http-fetch: set up git directory before parsing pack hashes t0410: mark test with SHA1 prerequisite t5308: make test work with SHA-256 t9700: make hash size independent t9500: ensure that algorithm info is preserved in config t9350: make hash size independent t9301: make hash size independent t9300: use $ZERO_OID instead of hard-coded object ID t9300: abstract away SHA-1-specific constants t8011: make hash size independent ...
2020-08-09test_cmp: diagnose incorrect argumentsLibravatar Eric Sunshine1-2/+14
Under normal circumstances, if a test author misspells a filename passed to test_cmp(), the error is quickly discovered when the test fails unexpectedly due to test_cmp() being unable to find the file. However, if the test is expected to fail, as with test_expect_failure(), a misspelled filename as argument to test_cmp() will go unnoticed since the test will indeed fail, but for the wrong reason. Make it easier for test authors to discover such problems early by sanity-checking the arguments to test_cmp(). To avoid penalizing all clients of test_cmp() in the general case, only check for missing files if the comparison fails. While at it, make test_cmp_bin() sanity-check its arguments, as well. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-30t: allow testing different hash algorithms via environmentLibravatar brian m. carlson1-3/+1
To allow developers to run the testsuite with a different algorithm than the default, provide an environment variable, GIT_TEST_DEFAULT_HASH, to specify the algorithm to use. Compute the fixed constants using test_oid. Move the constant initialization down below the point where test-lib-functions.sh is loaded so the functions are defined. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-30t: add test_oid option to select hash algorithmLibravatar brian m. carlson1-1/+11
In some tests, we have data files which are written with a particular hash algorithm. Instead of keeping two copies of the test files, we can keep one, and translate the value on the fly. In order to do so, we'll need to read both the source algorithm and the current algorithm, so add an optional flag to the test_oid helper that lets us look up a value for a specified hash algorithm. This should not cause any conflicts with existing tests, since key arguments to test_oid are allowed to contains only shell identifier characters. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-07test-lib-functions: restrict test_must_fail usageLibravatar Denton Liu1-0/+47
In previous commits, we removed the usage of test_must_fail() for most commands except for a set of pre-approved commands. Since that's done, only allow test_must_fail() to run those pre-approved commands. Obviously, we should allow `git`. We allow `__git*` as some completion functions return an error code that comes from a git invocation. It's good to avoid using test_must_fail unnecessarily but it wouldn't hurt to err on the side of caution when we're potentially wrapping a git command (like in these cases). We also allow `test-tool` and `test-svn-fe` because these are helper commands that are written by us and we want to catch their failure. Finally, we allow `test_terminal` because `test_terminal` just wraps around git commands. Also, we cannot rewrite `test_must_fail test_terminal` as `test_terminal test_must_fail` because test_must_fail() is a shell function and as a result, it cannot be invoked from the test-terminal Perl script. We opted to explicitly list the above tools instead of using a catch-all such as `test[-_]*` because we want to be as restrictive as possible so that in the future, someone would not accidentally introduce an unrelated usage of test_must_fail() on an "unapproved" command. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28Merge branch 'dd/test-with-busybox'Libravatar Junio C Hamano1-1/+1
Various tests have been updated to work around issues found with shell utilities that come with busybox etc. * dd/test-with-busybox: t5703: feed raw data into test-tool unpack-sideband t4124: tweak test so that non-compliant diff(1) can also be used t7063: drop non-POSIX argument "-ls" from find(1) t5616: use rev-parse instead to get HEAD's object_id t5003: skip conversion test if unzip -a is unavailable t5003: drop the subshell in test_lazy_prereq test-lib-functions: test_cmp: eval $GIT_TEST_CMP t4061: use POSIX compliant regex(7)
2020-04-22Merge branch 'js/mingw-is-hidden-test-fix'Libravatar Junio C Hamano1-0/+10
A Windows-specific test element has been made more robust against misuse from both user's environment and programmer's errors. * js/mingw-is-hidden-test-fix: t: restrict `is_hidden` to be called only on Windows mingw: make test_path_is_hidden more robust t: consolidate the `is_hidden` functions
2020-04-11t: restrict `is_hidden` to be called only on WindowsLibravatar Johannes Schindelin1-2/+5
The function won't work anywhere else, so let's mark it as an explicit bug if it is called on a non-Windows platform. Let's also rename the function to avoid cluttering the global namespace with an overly-generic function name. While at it, we also fix the code comment above that function: the lower-case `windows` refers to something different than `Windows`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-11mingw: make test_path_is_hidden more robustLibravatar Johannes Schindelin1-1/+1
This function uses Windows' system tool `attrib` to determine the state of the hidden flag of a file or directory. We should not actually expect the first `attrib.exe` in the PATH to be the one we are looking for. Or that it is in the PATH, for that matter. Let's use the full path to the tool instead. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-11t: consolidate the `is_hidden` functionsLibravatar Johannes Schindelin1-0/+7
The `is_hidden` function can be used (only on Windows) to determine whether a directory or file have their `hidden` flag set. This function is duplicated between two test scripts. It is better to move it into `test-lib-functions.sh` so that it is reused. This patch is best viewed with `--color-moved`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-29test-lib-functions: simplify packetize() stdin codeLibravatar Jeff King1-5/+4
The code path in packetize() for reading stdin needs to handle NUL bytes, so we can't rely on shell variables. However, the current code takes a whopping 4 processes and uses a temporary file. We can do this much more simply and efficiently by using a single perl invocation (and we already rely on perl in the matching depacketize() function). We'll keep the non-stdin code path as it is, since that uses zero extra processes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-27test-lib-functions: make packetize() more efficientLibravatar Jeff King1-7/+16
The packetize() function takes its input on stdin, and requires 4 separate sub-processes to format a simple string. We can do much better by getting the length via the shell's "${#packet}" construct. The one caveat is that the shell can't put a NUL into a variable, so we'll have to continue to provide the stdin form for a few calls. There are a few other cleanups here in the touched code: - the stdin form of packetize() had an extra stray "%s" when printing the packet - the converted calls in t5562 can be made simpler by redirecting output as a block, rather than repeated appending Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-25test-lib-functions: test_cmp: eval $GIT_TEST_CMPLibravatar Đoàn Trần Công Danh1-1/+1
Shell recognises first non-assignment token as command name. With /bin/sh linked to either /bin/bash or /bin/dash, `cd t/perf && ./p0000-perf-lib-sanity.sh -d -i -v` reports: > test_cmp:1: command not found: diff -u Using `eval` to unquote $GIT_TEST_CMP as same as precedence in `git_editor`. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-14t5310: factor out bitmap traversal comparisonLibravatar Jeff King1-0/+27
We check the results of "rev-list --use-bitmap-index" by comparing it to the same traversal without the bitmap option. However, this is a little tricky to do because of some output differences (see the included comment for details). Let's pull this out into a helper function, since we'll be adding some similar tests. While we're at it, let's also try to confirm that the bitmap output did indeed use bitmaps. Since the code internally falls back to the non-bitmap path in some cases, the tests are at risk of becoming trivial noops. This is a bit fragile, as not all outputs will differ (e.g., looking at only the commits from a fully-bitmapped pack will end up exactly the same as the normal traversal order, since it also matches the pack order). So we'll provide an escape hatch by which tests can disable this check (which should only be used after manually confirming that bitmaps kicked in). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-10Merge branch 'sg/test-squelch-noise-in-commit-bulk'Libravatar Junio C Hamano1-1/+1
Code cleanup. * sg/test-squelch-noise-in-commit-bulk: test-lib-functions: suppress a 'git rev-parse' error in 'test_commit_bulk'
2019-12-05Merge branch 'sg/test-bool-env'Libravatar Junio C Hamano1-1/+29
Recently we have declared that GIT_TEST_* variables take the usual boolean values (it used to be that some used "non-empty means true" and taking GIT_TEST_VAR=YesPlease as true); make sure we notice and fail when non-bool strings are given to these variables. * sg/test-bool-env: t5608-clone-2gb.sh: turn GIT_TEST_CLONE_2GB into a bool tests: add 'test_bool_env' to catch non-bool GIT_TEST_* values
2019-11-27test-lib-functions: suppress a 'git rev-parse' error in 'test_commit_bulk'Libravatar SZEDER Gábor1-1/+1
When 'test_commit_bulk' is invoked in an empty test repository, it prints a "fatal: Needed a single revision" error, but still does what it's supposed to do. A test helper function displaying a fatal error and still succeeding is always suspect to be buggy, but luckily that's not the case here: that error comes from a 'git rev-parse --verify HEAD' command invoked in a condition, which doesn't have anything to verify in an empty repository. Use the '--quiet' option to suppress that error message. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-23tests: add 'test_bool_env' to catch non-bool GIT_TEST_* valuesLibravatar SZEDER Gábor1-1/+29
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-21t: teach test_cmp_rev to accept ! for not-equalsLibravatar Denton Liu1-4/+15
In the case where we are using test_cmp_rev() to report not-equals, we write `! test_cmp_rev`. However, since test_cmp_rev() contains r1=$(git rev-parse --verify "$1") && r2=$(git rev-parse --verify "$2") && `! test_cmp_rev` will succeed if any of the rev-parses fail. This behavior is not desired. We want the rev-parses to _always_ be successful. Rewrite test_cmp_rev() to optionally accept "!" as the first argument to do a not-equals comparison. Rewrite `! test_cmp_rev` to `test_cmp_rev !` in all tests to take advantage of this new functionality. Also, rewrite the rev-parse logic to end with a `|| return 1` instead of &&-chaining into the rev-comparison logic. This makes it obvious to future readers that we explicitly intend on returning early if either of the rev-parses fail. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15Merge branch 'dl/octopus-graph-bug'Libravatar Junio C Hamano1-2/+4
"git log --graph" for an octopus merge is sometimes colored incorrectly, which is demonstrated and documented but not yet fixed. * dl/octopus-graph-bug: t4214: demonstrate octopus graph coloring failure t4214: explicitly list tags in log t4214: generate expect in their own test cases t4214: use test_merge test-lib: let test_merge() perform octopus merges
2019-10-04test-lib: let test_merge() perform octopus mergesLibravatar Denton Liu1-2/+4
Currently test_merge() only allows developers to merge in one branch. However, this restriction is artificial and there is no reason why it needs to be this way. Extend test_merge() to allow the specification of multiple branches so that octopus merges can be performed. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-22Merge branch 'sg/show-failed-test-names'Libravatar Junio C Hamano1-2/+2
The first line of verbose output from each test piece now carries the test name and number to help scanning with eyeballs. * sg/show-failed-test-names: tests: show the test name and number at the start of verbose output t0000-basic: use realistic test script names in the verbose tests
2019-08-09Merge branch 'bc/hash-independent-tests-part-4'Libravatar Junio C Hamano1-1/+2
Test fix. * bc/hash-independent-tests-part-4: t0000: reword comments for "local" test t: decrease nesting in test_oid_to_path
2019-08-08t: decrease nesting in test_oid_to_pathLibravatar Jonathan Nieder1-1/+2
t1410.3 ("corrupt and checks") fails when run using dash versions before 0.5.8, with a cryptic message: mv: cannot stat '.git/objects//e84adb2704cbd49549e52169b4043871e13432': No such file or directory The function generating that path: test_oid_to_path () { echo "${1%${1#??}}/${1#??}" } which is supposed to produce a result like 12/3456789.... But a dash bug[*] causes it to instead expand to /3456789... The stream of symbols that makes up this function is hard for humans to follow, too. The complexity mostly comes from the repeated use of the expression ${1#??} for the basename of the loose object. Use a variable instead --- nowadays, the dialect of shell used by Git permits local variables, so this is cheap. An alternative way to work around [*] is to remove the double-quotes around test_oid_to_path's return value. That makes the expression easier for dash to read, but harder for humans. Let's prefer the rephrasing that's helpful for humans, too. Noticed by building on Ubuntu trusty, which uses dash 0.5.7. [*] Fixed by v0.5.8~13 ("[EXPAND] Propagate EXP_QPAT in subevalvar, 2013-08-23). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>