summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2020-05-31Merge branch 'cb/test-use-ere-for-alternation'Libravatar Junio C Hamano2-2/+2
Portability fix for tests added recently. * cb/test-use-ere-for-alternation: t: avoid alternation (not POSIX) in grep's BRE
2020-05-29t: avoid alternation (not POSIX) in grep's BRELibravatar Carlo Marcelo Arenas Belón2-2/+2
f1e3df3169 (t: increase test coverage of signature verification output, 2020-03-04) adds GPG dependent tests to t4202 and t6200 that were found problematic with at least OpenBSD 6.7. Using an escaped '|' for alternations works only in some implementations of grep (e.g. GNU and busybox). It is not part of POSIX[1] and not supported by some BSD, macOS, and possibly other POSIX compatible implementations. Use `grep -E`, and write it using extended regular expression. [1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03 Helped-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-24Merge branch 'dd/t5703-grep-a-fix'Libravatar Junio C Hamano1-3/+6
Update an unconditional use of "grep -a" with a perl script in a test. * dd/t5703-grep-a-fix: t5703: replace "grep -a" usage by perl
2020-05-24Merge branch 'gs/commit-graph-path-filter'Libravatar Junio C Hamano1-1/+1
Test fix. * gs/commit-graph-path-filter: t4216: avoid unnecessary subshell in test_bloom_filters_not_used
2020-05-24Merge branch 'dl/merge-autostash'Libravatar Junio C Hamano1-1/+1
Test fix. * dl/merge-autostash: t5520: avoid alternation in grep's BRE (not POSIX)
2020-05-24Merge branch 'jt/avoid-prefetch-when-able-in-diff'Libravatar Junio C Hamano1-2/+2
Test-coverage enhancement. * jt/avoid-prefetch-when-able-in-diff: t4067: make rename detection test output raw diff
2020-05-24Merge branch 'gp/hppa-stack-test-fix'Libravatar Junio C Hamano1-2/+10
Platform dependent tweak to a test for HP-PA. * gp/hppa-stack-test-fix: tests: skip small-stack tests on hppa architecture
2020-05-20t5520: avoid alternation in grep's BRE (not POSIX)Libravatar Carlo Marcelo Arenas Belón1-1/+1
Instead of using a BRE, that broke tests 30-32, 37-39, 42 at least with OpenBSD 6.7; use a simpler ERE. Fixes: d9f15d37f1 (pull: pass --autostash to merge, 2020-04-07) Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-20t4216: avoid unnecessary subshell in test_bloom_filters_not_usedLibravatar Carlo Marcelo Arenas Belón1-1/+1
Seems to trigger a bug in at least OpenBSD's 6.7 sh where it is interpreted as a history lookup and therefore fails 125-126, 128, 130. Remove the subshell and get a space between ! and grep, so tests pass successfully. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-20Merge branch 'jc/fix-tap-output-under-bash'Libravatar Junio C Hamano1-15/+1
A recent attempt to make the test output nicer to view on CI systems broke TAP output under bash. The effort has been reverted to be re-attempted in the next cycle. * jc/fix-tap-output-under-bash: Revert "tests: when run in Bash, annotate test failures with file name/line number" Revert "ci: add a problem matcher for GitHub Actions" Revert "t/test_lib: avoid naked bash arrays in file_lineno"
2020-05-20Merge branch 'en/merge-rename-rename-worktree-fix'Libravatar Junio C Hamano1-0/+55
When a binary file gets modified and renamed on both sides of history to different locations, both files would be written to the working tree but both would have the contents from "ours". This has been corrected so that the path from each side gets their original content. * en/merge-rename-rename-worktree-fix: merge-recursive: fix rename/rename(1to2) for working tree with a binary
2020-05-20Merge branch 'dd/t1509-i18n-fix'Libravatar Junio C Hamano1-2/+2
A few tests were not i18n clean. * dd/t1509-i18n-fix: t1509: correct i18n test
2020-05-19t4067: make rename detection test output raw diffLibravatar Jonathan Tan1-2/+2
95acf11a3d ("diff: restrict when prefetching occurs", 2020-04-07) taught diff to prefetch blobs in a more limited set of situations. These limited situations include when the output format requires blob data, and when inexact rename detection is needed. There is an existing test case that tests inexact rename detection, but it also uses an output format that requires blob data, resulting in the inexact-rename-detection-only code not being tested. Update this test to use the raw output format, which does not require blob data. Thanks to Derrick Stolee for noticing this lapse in code coverage and for doing the preliminary analysis [1]. [1] https://lore.kernel.org/git/853759d3-97c3-241f-98e1-990883cd204e@gmail.com/ Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-19t5703: replace "grep -a" usage by perlLibravatar Đoàn Trần Công Danh1-3/+6
On some platforms likes HP-UX, grep(1) doesn't understand "-a". Let's switch to perl. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-18tests: skip small-stack tests on hppa architectureLibravatar Greg Price1-2/+10
On hppa these tests crash because the allocated stack space is too small, even after it was doubled in b9a190789 (and the data size doubled to match) to make it work on powerpc. For this arch just skip these tests, which is enough to make the whole suite pass. Fixes: https://bugs.debian.org/757402 Based-on-patch-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Greg Price <gnprice@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-15Revert "tests: when run in Bash, annotate test failures with file name/line ↵Libravatar Junio C Hamano1-13/+1
number" This reverts commit 662f9cf1548cf069cb819e9e95f224657015fcf9, to fix the TAP output broken for bash.
2020-05-15Revert "t/test_lib: avoid naked bash arrays in file_lineno"Libravatar Junio C Hamano1-10/+8
This reverts commit 303775a25f0b4ac5d6ad2e96eb4404c24209cad8; instead of trying to salvage the tap-breaking change, let's revert the whole thing for now.
2020-05-14Merge branch 'es/trace-log-progress'Libravatar Junio C Hamano1-0/+26
Teach codepaths that show progress meter to also use the start_progress() and the stop_progress() calls as a "region" to be traced. * es/trace-log-progress: trace2: log progress time and throughput
2020-05-14Merge branch 'jt/t5500-unflake'Libravatar Junio C Hamano1-6/+6
Test fix for a topic already in 'master' and meant for 'maint'. * jt/t5500-unflake: t5500: count objects through stderr, not trace
2020-05-14Merge branch 'sn/midx-repack-with-config'Libravatar Junio C Hamano1-0/+27
"git multi-pack-index repack" has been taught to honor some repack.* configuration variables. * sn/midx-repack-with-config: multi-pack-index: respect repack.packKeptObjects=false midx: teach "git multi-pack-index repack" honor "git repack" configurations
2020-05-14Merge branch 'ds/bloom-cleanup'Libravatar Junio C Hamano2-4/+4
Code cleanup and typofixes * ds/bloom-cleanup: completion: offer '--(no-)patch' among 'git log' options bloom: use num_changes not nr for limit detection bloom: de-duplicate directory entries Documentation: changed-path Bloom filters use byte words bloom: parse commit before computing filters test-bloom: fix usage typo bloom: fix whitespace around tab length
2020-05-14Merge branch 'rs/fsck-duplicate-names-in-trees'Libravatar Junio C Hamano1-0/+16
"git fsck" ensures that the paths recorded in tree objects are sorted and without duplicates, but it failed to notice a case where a blob is followed by entries that sort before a tree with the same name. This has been corrected. * rs/fsck-duplicate-names-in-trees: fsck: report non-consecutive duplicate names in trees
2020-05-14Merge branch 'ao/p4-d-f-conflict-recover'Libravatar Junio C Hamano1-0/+70
"git p4" learned to recover from a (broken) state where a directory and a file are recorded at the same path in the Perforce repository the same way as their clients do. * ao/p4-d-f-conflict-recover: git-p4: recover from inconsistent perforce history
2020-05-14Merge branch 'js/rebase-autosquash-double-fixup-fix'Libravatar Junio C Hamano1-0/+16
"rebase -i" segfaulted when rearranging a sequence that has a fix-up that applies another fix-up (which may or may not be a fix-up of yet another step). * js/rebase-autosquash-double-fixup-fix: rebase --autosquash: fix a potential segfault
2020-05-14Merge branch 'cw/bisect-replay-with-dos'Libravatar Junio C Hamano1-0/+7
"git bisect replay" had trouble with input files when they used CRLF line ending, which has been corrected. * cw/bisect-replay-with-dos: bisect: allow CRLF line endings in "git bisect replay" input
2020-05-14Merge branch 'es/bugreport-with-hooks'Libravatar Junio C Hamano1-0/+15
"git bugreport" learned to report enabled hooks in the repository. * es/bugreport-with-hooks: bugreport: collect list of populated hooks
2020-05-14merge-recursive: fix rename/rename(1to2) for working tree with a binaryLibravatar Elijah Newren1-0/+55
With a rename/rename(1to2) conflict, we attempt to do a three-way merge of the file contents, so that the correct contents can be placed in the working tree at both paths. If the file is a binary, however, no content merging is possible and we should just use the original version of the file at each of the paths. Reported-by: Chunlin Zhang <zhangchunlin@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-13Merge branch 'cc/upload-pack-v2-fetch-fix'Libravatar Junio C Hamano1-4/+3
Serving a "git fetch" client over "git://" and "ssh://" protocols using the on-wire protocol version 2 was buggy on the server end when the client needs to make a follow-up request to e.g. auto-follow tags. * cc/upload-pack-v2-fetch-fix: upload-pack: clear filter_options for each v2 fetch command
2020-05-13Merge branch 'dd/bloom-sparse-fix'Libravatar Junio C Hamano3-3/+3
Code clean-up. * dd/bloom-sparse-fix: bloom: fix `make sparse` warning
2020-05-13Merge branch 'tb/bitmap-walk-with-tree-zero-filter'Libravatar Junio C Hamano2-0/+31
The object walk with object filter "--filter=tree:0" can now take advantage of the pack bitmap when available. * tb/bitmap-walk-with-tree-zero-filter: pack-bitmap: pass object filter to fill-in traversal pack-bitmap.c: support 'tree:0' filtering pack-bitmap.c: make object filtering functions generic list-objects-filter: treat NULL filter_options as "disabled"
2020-05-13t1509: correct i18n testLibravatar Đoàn Trần Công Danh1-2/+2
git-init(1)'s messages is subjected to i18n. They should be tested by test_i18n* family. Fix them. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-12trace2: log progress time and throughputLibravatar Emily Shaffer1-0/+26
Rather than teaching only one operation, like 'git fetch', how to write down throughput to traces, we can learn about a wide range of user operations that may seem slow by adding tooling to the progress library itself. Operations which display progress are likely to be slow-running and the kind of thing we want to monitor for performance anyways. By showing object counts and data transfer size, we should be able to make some derived measurements to ensure operations are scaling the way we expect. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-11bloom: use num_changes not nr for limit detectionLibravatar Derrick Stolee1-1/+1
As diff_tree_oid() computes a diff, it will terminate early if the total number of changed paths is strictly larger than max_changes. This includes the directories that changed, not just the file paths. However, only the file paths are reflected in the resulting diff queue's "nr" value. Use the "num_changes" from diffopt to check if the diff terminated early. This is incredibly important, as it can result in incorrect filters! For example, the first commit in the Linux kernel repo reports only 471 changes, but since these are nested inside several directories they expand to 513 "real" changes, and in fact the total list of changes is not reported. Thus, the computed filter for this commit is incorrect. Demonstrate the subtle difference by using one fewer file change in the 'get bloom filter for commit with 513 changes' test. Before, this edited 513 files inside "bigDir" which hit this inequality. However, dropping the file count by one demonstrates how the previous inequality was incorrect but the new one is correct. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-11bloom: de-duplicate directory entriesLibravatar Derrick Stolee1-2/+2
When computing a changed-path Bloom filter, we need to take the files that changed from the diff computation and extract the parent directories. That way, a directory pathspec such as "Documentation" could match commits that change "Documentation/git.txt". However, the current code does a poor job of this process. The paths are added to a hashmap, but we do not check if an entry already exists with that path. This can create many duplicate entries and cause the filter to have a much larger length than it should. This means that the filter is more sparse than intended, which helps the false positive rate, but wastes a lot of space. Properly use hashmap_get() before hashmap_add(). Also be sure to include a comparison function so these can be matched correctly. This has an effect on a test in t0095-bloom.sh. This makes sense, there are ten changes inside "smallDir" so the total number of paths in the filter should be 11. This would result in 11 * 10 bits required, and with 8 bits per byte, this results in 14 bytes. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-11fsck: report non-consecutive duplicate names in treesLibravatar René Scharfe1-0/+16
Tree entries are sorted in path order, meaning that directory names get a slash ('/') appended implicitly. Git fsck checks if trees contains consecutive duplicates, but due to that ordering there can be non-consecutive duplicates as well if one of them is a directory and the other one isn't. Such a tree cannot be fully checked out. Find these duplicates by recording candidate file names on a stack and check candidate directory names against that stack to find matches. Suggested-by: Brandon Williams <bwilliamseng@gmail.com> Original-test-by: Brandon Williams <bwilliamseng@gmail.com> Signed-off-by: René Scharfe <l.s.r@web.de> Reviewed-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-10git-p4: recover from inconsistent perforce historyLibravatar Andrew Oakley1-0/+70
Perforce allows you commit files and directories with the same name, so you could have files //depot/foo and //depot/foo/bar both checked in. A p4 sync of a repository in this state fails. Deleting one of the files recovers the repository. When this happens we want git-p4 to recover in the same way as perforce. Note that Perforce has this change in their 2017.1 version: Bugs fixed in 2017.1 #1489051 (Job #2170) ** Submitting a file with the same name as an existing depot directory path (or vice versa) will now be rejected. so people hopefully will not creating damaged Perforce repos anymore, but "git p4" needs to be able to interact with already corrupt ones. Signed-off-by: Andrew Oakley <andrew@adoakley.name> Reviewed-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-10multi-pack-index: respect repack.packKeptObjects=falseLibravatar Derrick Stolee1-0/+27
When selecting a batch of pack-files to repack in the "git multi-pack-index repack" command, Git should respect the repack.packKeptObjects config option. When false, this option says that the pack-files with an associated ".keep" file should not be repacked. This config value is "false" by default. There are two cases for selecting a batch of objects. The first is the case where the input batch-size is zero, which specifies "repack everything". The second is with a non-zero batch size, which selects pack-files using a greedy selection criteria. Both of these cases are updated and tested. Reported-by: Son Luong Ngoc <sluongng@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-09rebase --autosquash: fix a potential segfaultLibravatar Johannes Schindelin1-0/+16
When rearranging the todo list so that the fixups/squashes are reordered just after the commits they intend to fix up, we use two arrays to maintain that list: `next` and `tail`. The idea is that `next[i]`, if set to a non-negative value, contains the index of the item that should be rearranged just after the `i`th item. To avoid having to walk the entire `next` chain when appending another fixup/squash, we also store the end of the `next` chain in `tail[i]`. The logic we currently use to update these array items is based on the assumption that given a fixup/squash item at index `i`, we just found the index `i2` indicating the first item in that fixup chain. However, as reported by Paul Ganssle, that need not be true: the special form `fixup! <commit-hash>` is allowed to point to _another_ fixup commit in the middle of the fixup chain. Example: * 0192a To fixup * 02f12 fixup! To fixup * 03763 fixup! To fixup * 04ecb fixup! 02f12 Note how the fourth commit targets the second commit, which is already a fixup that targets the first commit. Previously, we would update `next` and `tail` under our assumption that every `fixup!` commit would find the start of the `fixup!`/`squash!` chain. This would lead to a segmentation fault because we would actually end up with a `next[i]` pointing to a `fixup!` but the corresponding `tail[i]` pointing nowhere, which would the lead to a segmentation fault. Let's fix this by _inserting_, rather than _appending_, the item. In other words, if we make a given line successor of another line, we do not simply forget any previously set successor of the latter, but make it a successor of the former. In the above example, at the point when we insert 04ecb just after 02f12, 03763 would already be recorded as a successor of 04ecb, and we now "squeeze in" 04ecb. To complete the idea, we now no longer assume that `next[i]` pointing to a line means that `last[i]` points to a line, too. Instead, we extend the concept of `last` to cover also partial `fixup!`/`squash!` chains, i.e. chains starting in the middle of a larger such chain. In the above example, after processing all lines, `last[0]` (corresponding to 0192a) would point to 03763, which indeed is the end of the overall `fixup!` chain, and `last[1]` (corresponding to 02f12) would point to 04ecb (which is the last `fixup!` targeting 02f12, but it has 03763 as successor, i.e. it is not the end of overall `fixup!` chain). Reported-by: Paul Ganssle <paul@ganssle.io> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-08Merge branch 'cb/test-bash-lineno-fix'Libravatar Junio C Hamano1-8/+10
Recent change to show files and line numbers of a breakage during test (only available when running the tests with bash) were hurting other shells with syntax errors, which has been corrected. * cb/test-bash-lineno-fix: t/test_lib: avoid naked bash arrays in file_lineno
2020-05-08Merge branch 'cb/t0000-use-the-configured-shell'Libravatar Junio C Hamano1-5/+2
The basic test did not honor $TEST_SHELL_PATH setting, which has been corrected. * cb/t0000-use-the-configured-shell: t/t0000-basic: make sure subtests also use TEST_SHELL_PATH
2020-05-08Merge branch 'es/restore-staged-from-head-by-default'Libravatar Junio C Hamano1-0/+11
"git restore --staged --worktree" now defaults to take the contents out of "HEAD", instead of erring out. * es/restore-staged-from-head-by-default: restore: default to HEAD when combining --staged and --worktree
2020-05-08Merge branch 'ds/sparse-allow-empty-working-tree'Libravatar Junio C Hamano2-8/+12
The sparse-checkout patterns have been forbidden from excluding all paths, leaving an empty working tree, for a long time. This limitation has been lifted. * ds/sparse-allow-empty-working-tree: sparse-checkout: stop blocking empty workdirs
2020-05-08Merge branch 'jk/for-each-ref-multi-key-sort-fix'Libravatar Junio C Hamano1-6/+88
"git branch" and other "for-each-ref" variants accepted multiple --sort=<key> options in the increasing order of precedence, but it had a few breakages around "--ignore-case" handling, and tie-breaking with the refname, which have been fixed. * jk/for-each-ref-multi-key-sort-fix: ref-filter: apply fallback refname sort only after all user sorts ref-filter: apply --ignore-case to all sorting keys
2020-05-08Merge branch 'ah/userdiff-markdown'Libravatar Junio C Hamano3-0/+24
The userdiff patterns for Markdown documents have been added. * ah/userdiff-markdown: userdiff: support Markdown
2020-05-08Merge branch 'cb/credential-store-ignore-bogus-lines'Libravatar Junio C Hamano1-1/+90
With the recent tightening of the code that is used to parse various parts of a URL for use in the credential subsystem, a hand-edited credential-store file causes the credential helper to die, which is a bit too harsh to the users. Demote the error behaviour to just ignore and keep using well-formed lines instead. * cb/credential-store-ignore-bogus-lines: credential-store: ignore bogus lines from store file credential-store: document the file format a bit more
2020-05-08upload-pack: clear filter_options for each v2 fetch commandLibravatar Christian Couder1-4/+3
Because of the request/response model of protocol v2, the upload_pack_v2() function is sometimes called twice in the same process, while 'struct list_objects_filter_options filter_options' was declared as static at the beginning of 'upload-pack.c'. This made the check in list_objects_filter_die_if_populated(), which is called by process_args(), fail the second time upload_pack_v2() is called, as filter_options had already been populated the first time. To fix that, filter_options is not static any more. It's now owned directly by upload_pack(). It's now also part of 'struct upload_pack_data', so that it's owned indirectly by upload_pack_v2(). In the long term, the goal is to also have upload_pack() use 'struct upload_pack_data', so adding filter_options to this struct makes more sense than to have it owned directly by upload_pack_v2(). This fixes the first of the 2 bugs documented by d0badf8797 (partial-clone: demonstrate bugs in partial fetch, 2020-02-21). Helped-by: Derrick Stolee <dstolee@microsoft.com> Helped-by: Jeff King <peff@peff.net> Helped-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-08bisect: allow CRLF line endings in "git bisect replay" inputLibravatar Christopher Warrington1-0/+7
We advertise that the bisect log can be corrected in your editor before being fed to "git bisect replay", but some editors may turn the line endings to CRLF. Update the parser of the input lines so that the CR at the end of the line gets ignored. Were anyone to intentionally be using terms/revs with embedded CRs, replaying such bisects will no longer work with this change. I suspect that this is incredibly rare. Signed-off-by: Christopher Warrington <chwarr@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-07bugreport: collect list of populated hooksLibravatar Emily Shaffer1-0/+15
Occasionally a failure a user is seeing may be related to a specific hook which is being run, perhaps without the user realizing. While the contents of hooks can be sensitive - containing user data or process information specific to the user's organization - simply knowing that a hook is being run at a certain stage can help us to understand whether something is going wrong. Without a definitive list of hook names within the code, we compile our own list from the documentation. This is likely prone to bitrot, but designing a single source of truth for acceptable hooks is too much overhead for this small change to the bugreport tool. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-07bloom: fix `make sparse` warningLibravatar Đoàn Trần Công Danh3-3/+3
* We need a `final_new_line` to make our source code as text file, per POSIX and C specification. * `bloom_filters` should be limited to interal linkage only Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-07t/test_lib: avoid naked bash arrays in file_linenoLibravatar Carlo Marcelo Arenas Belón1-8/+10
662f9cf154 (tests: when run in Bash, annotate test failures with file name/line number, 2020-04-11), introduces a way to report the location (file:lineno) of a failed test case by traversing the bash callstack. The implementation requires bash and uses shell arrays and is therefore protected by a guard but NetBSD sh will still have to parse the function and therefore will result in: ** t0000-basic.sh *** ./test-lib.sh: 681: Syntax error: Bad substitution Enclose the bash specific code inside an eval to avoid parsing errors in the same way than 5826b7b595 (test-lib: check Bash version for '-x' without using shell arrays, 2019-01-03) Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>