summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2020-06-24testsvn: respect `init.defaultBranch`Libravatar Johannes Schindelin1-0/+6
The default name of the initial branch in new repositories can now be configured. The `testsvn` remote helper translates the remote Subversion repository's branch name `trunk` to the hard-coded name `master`. Clearly, the intention was to make the name align with Git's defaults. So while we are not talking about a newly-created repository in the `testsvn` context, it is a newly-created _Git_ repository, si it _still_ makes sense to use the overridden default name for the initial branch whenever users configured it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24remote: use the configured default branch name when appropriateLibravatar Johannes Schindelin1-1/+10
When guessing the default branch name of a remote, and there are no refs to guess from, we want to go with the preference specified by the user for the fall-back, i.e. the default name to be used for the initial branch of new repositories (because as far as the user is concerned, a remote that has no branches yet is a new repository). At the same time, when talking to an older Git server that does not report a symref for `HEAD` (but instead reports a commit hash), let's try to guess the configured default branch name first. If it does not match the reported commit hash, let's fall back to `master` as before. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24clone: use configured default branch name when appropriateLibravatar Johannes Schindelin1-0/+15
When cloning a repository without any branches, Git chooses a default branch name for the as-yet unborn branch. As part of the implicit initialization of the local repository, Git just learned to respect `init.defaultBranch` to choose a different initial branch name. We now really want that branch name to be used as a fall-back. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24init: allow setting the default for the initial branch name via the configLibravatar Don Goodman-Wilson1-0/+13
We just introduced the command-line option `--initial-branch=<branch-name>` to allow initializing a new repository with a different initial branch than the hard-coded one. To allow users to override the initial branch name more permanently (i.e. without having to specify the name manually for each and every `git init` invocation), let's introduce the `init.defaultBranch` config setting. Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Helped-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Don Goodman-Wilson <don@goodman-wilson.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24init: allow specifying the initial branch name for the new repositoryLibravatar Johannes Schindelin1-0/+13
There is a growing number of projects and companies desiring to change the main branch name of their repositories (see e.g. https://twitter.com/mislav/status/1270388510684598272 for background on this). To change that branch name for new repositories, currently the only way to do that automatically is by copying all of Git's template directory, then hard-coding the desired default branch name into the `.git/HEAD` file, and then configuring `init.templateDir` to point to those copied template files. To make this process much less cumbersome, let's introduce a new option: `--initial-branch=<branch-name>`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24submodule: fall back to remote's HEAD for missing remote.<name>.branchLibravatar Johannes Schindelin2-2/+21
When `remote.<name>.branch` is not configured, `git submodule update` currently falls back to using the branch name `master`. A much better idea, however, is to use the remote `HEAD`: on all Git servers running reasonably recent Git versions, the symref `HEAD` points to the main branch. Note: t7419 demonstrates that there _might_ be use cases out there that _expect_ `git submodule update --remote` to update submodules to the remote `master` branch even if the remote `HEAD` points to another branch. Arguably, this patch makes the behavior more intuitive, but there is a slight possibility that this might cause regressions in obscure setups. Even so, it should be okay to fix this behavior without anything like a longer transition period: - The `git submodule update --remote` command is not really common. - Current Git's behavior when running this command is outright confusing, unless the remote repository's current branch _is_ `master` (in which case the proposed behavior matches the old behavior). - If a user encounters a regression due to the changed behavior, the fix is actually trivial: setting `submodule.<name>.branch` to `master` will reinstate the old behavior. Helped-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24send-pack/transport-helper: avoid mentioning a particular branchLibravatar Johannes Schindelin1-0/+6
When trying to push all matching branches, but none match, we offer a message suggesting to push the `master` branch. However, we want to step away from making that branch any more special than any other branch, so let's reword that message to mention no branch in particular. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-23fmt-merge-msg: stop treating `master` speciallyLibravatar Johannes Schindelin28-93/+93
In the context of many projects renaming their primary branch names away from `master`, Git wants to stop treating the `master` branch specially. Let's start with `git fmt-merge-msg`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-08Merge branch 'jt/curl-verbose-on-trace-curl'Libravatar Junio C Hamano2-1/+37
Rewrite support for GIT_CURL_VERBOSE in terms of GIT_TRACE_CURL. Looking good. * jt/curl-verbose-on-trace-curl: http, imap-send: stop using CURLOPT_VERBOSE t5551: test that GIT_TRACE_CURL redacts password
2020-06-08Merge branch 'cb/bisect-helper-parser-fix'Libravatar Junio C Hamano1-0/+2
The code to parse "git bisect start" command line was lax in validating the arguments. * cb/bisect-helper-parser-fix: bisect--helper: avoid segfault with bad syntax in `start --term-*`
2020-06-08Merge branch 'js/checkout-p-new-file'Libravatar Junio C Hamano1-0/+19
"git checkout -p" did not handle a newly added path at all. * js/checkout-p-new-file: checkout -p: handle new files correctly
2020-06-08Merge branch 'dl/remote-curl-deadlock-fix'Libravatar Junio C Hamano6-0/+67
On-the-wire protocol v2 easily falls into a deadlock between the remote-curl helper and the fetch-pack process when the server side prematurely throws an error and disconnects. The communication has been updated to make it more robust. * dl/remote-curl-deadlock-fix: stateless-connect: send response end packet pkt-line: define PACKET_READ_RESPONSE_END remote-curl: error on incomplete packet pkt-line: extern packet_length() transport: extract common fetch_pack() call remote-curl: remove label indentation remote-curl: fix typo
2020-06-08Merge branch 'bc/filter-process'Libravatar Junio C Hamano1-0/+8
Code simplification and test coverage enhancement. * bc/filter-process: t2060: add a test for switch with --orphan and --discard-changes builtin/checkout: simplify metadata initialization
2020-06-08Merge branch 'rs/fsck-duplicate-names-in-trees'Libravatar Junio C Hamano1-15/+28
The check in "git fsck" to ensure that the tree objects are sorted still had corner cases it missed unsorted entries. * rs/fsck-duplicate-names-in-trees: fsck: detect more in-tree d/f conflicts t1450: demonstrate undetected in-tree d/f conflict t1450: increase test coverage of in-tree d/f detection fsck: fix a typo in a comment
2020-06-08Merge branch 'tb/commit-graph-no-check-oids'Libravatar Junio C Hamano1-9/+16
Clean-up the commit-graph codepath. * tb/commit-graph-no-check-oids: commit-graph: drop COMMIT_GRAPH_WRITE_CHECK_OIDS flag t5318: reorder test below 'graph_read_expect' commit-graph.c: simplify 'fill_oids_from_commits' builtin/commit-graph.c: dereference tags in builtin builtin/commit-graph.c: extract 'read_one_commit()' commit-graph.c: peel refs in 'add_ref_to_set' commit-graph.c: show progress of finding reachable commits commit-graph.c: extract 'refs_cb_data'
2020-06-08Merge branch 'cb/t4210-illseq-auto-detect'Libravatar Junio C Hamano3-52/+125
As FreeBSD is not the only platform whose regexp library reports a REG_ILLSEQ error when fed invalid UTF-8, add logic to detect that automatically and skip the affected tests. * cb/t4210-illseq-auto-detect: t4210: detect REG_ILLSEQ dynamically and skip affected tests t/helper: teach test-regex to report pattern errors (like REG_ILLSEQ)
2020-06-08Merge branch 'ds/line-log-on-bloom'Libravatar Junio C Hamano1-0/+68
"git log -L..." now takes advantage of the "which paths are touched by this commit?" info stored in the commit-graph system. * ds/line-log-on-bloom: line-log: integrate with changed-path Bloom filters line-log: try to use generation number-based topo-ordering line-log: more responsive, incremental 'git log -L' t4211-line-log: add tests for parent oids line-log: remove unused fields from 'struct line_log_data'
2020-06-02Merge branch 'en/fast-import-looser-date'Libravatar Junio C Hamano1-0/+28
Some repositories in the wild have commits that record nonsense committer timezone (e.g. rails.git); "git fast-import" learned an option to pass these nonsense timestamps intact to allow recreating existing repositories as-is. * en/fast-import-looser-date: fast-import: add new --date-format=raw-permissive format
2020-06-02Merge branch 'la/diff-relative-config'Libravatar Junio C Hamano2-3/+92
The commands in the "diff" family learned to honor "diff.relative" configuration variable. * la/diff-relative-config: diff: add config option relative
2020-06-02Merge branch 'rs/checkout-b-track-error'Libravatar Junio C Hamano2-0/+34
The error message from "git checkout -b foo -t bar baz" was confusing. * rs/checkout-b-track-error: checkout: improve error messages for -b with extra argument checkout: add tests for -b and --track
2020-06-02Merge branch 'cb/t5608-cleanup'Libravatar Junio C Hamano1-6/+5
Test fixup. * cb/t5608-cleanup: t5608: avoid say() and use "skip_all" instead for consistency
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-31fast-import: add new --date-format=raw-permissive formatLibravatar Elijah Newren1-0/+28
There are multiple repositories in the wild with random, invalid timezones. Most notably is a commit from rails.git with a timezone of "+051800"[1]. A few searches will find other repos with that same invalid timezone as well. Further, Peff reports that GitHub relaxed their fsck checks in August 2011 to accept any timezone value[2], and there have been multiple reports to filter-repo about fast-import crashing while trying to import their existing repositories since they had timezone values such as "-7349423" and "-43455309"[3]. The existing check on timezone values inside fast-import may prove useful for people who are crafting fast-import input by hand or with a new script. For them, the check may help them avoid accidentally recording invalid dates. (Note that this check is rather simplistic and there are still several forms of invalid dates that fast-import does not check for: dates in the future, timezone values with minutes that are not divisible by 15, and timezone values with minutes that are 60 or greater.) While this simple check may have some value for those users, other users or tools will want to import existing repositories as-is. Provide a --date-format=raw-permissive format that will not error out on these otherwise invalid timezones so that such existing repositories can be imported. [1] https://github.com/rails/rails/commit/4cf94979c9f4d6683c9338d694d5eb3106a4e734 [2] https://lore.kernel.org/git/20200521195513.GA1542632@coredump.intra.peff.net/ [3] https://github.com/newren/git-filter-repo/issues/88 Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-27checkout -p: handle new files correctlyLibravatar Johannes Schindelin1-0/+19
The original patch selection code was written for `git add -p`, and the fundamental unit on which it works is a hunk. We hacked around that to handle deletions back in 24ab81ae4d (add-interactive: handle deletion of empty files, 2009-10-27). But `git add -p` would never see a new file, since we only consider the set of tracked files in the index. However, since the same machinery was used for `git checkout -p` & friends, we can see new files. Handle this case specifically, adding a new prompt for it that is modeled after the `deleted file` case. This also fixes the problem where added _empty_ files could not be staged via `git checkout -p`. Reported-by: Merlin Büge <toni@bluenox07.de> 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-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-24stateless-connect: send response end packetLibravatar Denton Liu1-0/+13
Currently, remote-curl acts as a proxy and blindly forwards packets between an HTTP server and fetch-pack. In the case of a stateless RPC connection where the connection is terminated before the transaction is complete, remote-curl will blindly forward the packets before waiting on more input from fetch-pack. Meanwhile, fetch-pack will read the transaction and continue reading, expecting more input to continue the transaction. This results in a deadlock between the two processes. This can be seen in the following command which does not terminate: $ git -c protocol.version=2 clone https://github.com/git/git.git --shallow-since=20151012 Cloning into 'git'... whereas the v1 version does terminate as expected: $ git -c protocol.version=1 clone https://github.com/git/git.git --shallow-since=20151012 Cloning into 'git'... fatal: the remote end hung up unexpectedly Instead of blindly forwarding packets, make remote-curl insert a response end packet after proxying the responses from the remote server when using stateless_connect(). On the RPC client side, ensure that each response ends as described. A separate control packet is chosen because we need to be able to differentiate between what the remote server sends and remote-curl's control packets. By ensuring in the remote-curl code that a server cannot send response end packets, we prevent a malicious server from being able to perform a denial of service attack in which they spoof a response end packet and cause the described deadlock to happen. Reported-by: Force Charlie <charlieio@outlook.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-24pkt-line: define PACKET_READ_RESPONSE_ENDLibravatar Denton Liu1-0/+4
In a future commit, we will use PACKET_READ_RESPONSE_END to separate messages proxied by remote-curl. To prepare for this, add the PACKET_READ_RESPONSE_END enum value. In switch statements that need a case added, die() or BUG() when a PACKET_READ_RESPONSE_END is unexpected. Otherwise, mirror how PACKET_READ_DELIM is implemented (especially in cases where packets are being forwarded). Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-24remote-curl: error on incomplete packetLibravatar Denton Liu5-0/+50
Currently, remote-curl acts as a proxy and blindly forwards packets between an HTTP server and fetch-pack. In the case of a stateless RPC connection where the connection is terminated with a partially written packet, remote-curl will blindly send the partially written packet before waiting on more input from fetch-pack. Meanwhile, fetch-pack will read the partial packet and continue reading, expecting more input. This results in a deadlock between the two processes. For a stateless connection, inspect packets before sending them and error out if a packet line packet is incomplete. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-24diff: add config option relativeLibravatar Laurent Arnoud2-3/+92
The `diff.relative` boolean option set to `true` shows only changes in the current directory/value specified by the `path` argument of the `relative` option and shows pathnames relative to the aforementioned directory. Teach `--no-relative` to override earlier `--relative` Add for git-format-patch(1) options documentation `--relative` and `--no-relative` Signed-off-by: Laurent Arnoud <laurent@spkdev.net> Acked-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-24t5608: avoid say() and use "skip_all" instead for consistencyLibravatar Carlo Marcelo Arenas Belón1-6/+5
Printing a message directly to stdout could affect TAP processing and is not really needed, as there is a standard way to skip all tests that could be used instead, while printing an equivalent message. While at it; update the message to better reflect that since a85efb5985 (t5608-clone-2gb.sh: turn GIT_TEST_CLONE_2GB into a bool, 2019-11-22), the enabling variable should be a recognized boolean (ex: true, false, 1, 0) and get rid of the prerequisite that used to guard all the tests, since "skip_all" is just much faster and idempotent. Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-24checkout: improve error messages for -b with extra argumentLibravatar René Scharfe2-2/+2
When we try to create a branch "foo" based on "origin/master" and give git commit -b an extra unsupported argument "bar", it confusingly reports: $ git checkout -b foo origin/master bar fatal: 'bar' is not a commit and a branch 'foo' cannot be created from it $ git checkout --track -b foo origin/master bar fatal: 'bar' is not a commit and a branch 'foo' cannot be created from it That's wrong, because it very well understands that "origin/master" is supposed to be the start point for the new branch and not "bar". Check if we got a commit and show more fitting messages in that case instead: $ git checkout -b foo origin/master bar fatal: Cannot update paths and switch to branch 'foo' at the same time. $ git checkout --track -b foo origin/master bar fatal: '--track' cannot be used with updating paths Original-patch-by: Jeff King <peff@peff.net> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-24checkout: add tests for -b and --trackLibravatar René Scharfe2-0/+34
Test git checkout -b with and without --track and demonstrate unexpected error messages when it's given an extra (i.e. unsupported) path argument. In both cases it reports: $ git checkout -b foo origin/master bar fatal: 'bar' is not a commit and a branch 'foo' cannot be created from it The problem is that the start point we gave for the new branch is "origin/master" and "bar" is just some extra argument -- it could even be a valid commit, which would make the message even more confusing. We have more fitting error messages in git commit, but get confused; use the text of the rights ones in the tests. Reported-by: Dana Dahlstrom <dahlstrom@google.com> Original-test-by: Jeff King <peff@peff.net> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-24bisect--helper: avoid segfault with bad syntax in `start --term-*`Libravatar Carlo Marcelo Arenas Belón1-0/+2
06f5608c14 (bisect--helper: `bisect_start` shell function partially in C, 2019-01-02) adds a lax parser for `git bisect start` which could result in a segfault under a bad syntax call for start with custom terms. Detect if there are enough arguments left in the command line to use for --term-{old,good,new,bad} and abort with the same syntax error the original implementation will show if not. While at it, remove an unnecessary (and incomplete) check for unknown arguments and make sure to add a test to avoid regressions. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Acked-by: Christian Couder <christian.couder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-21fsck: detect more in-tree d/f conflictsLibravatar René Scharfe1-1/+1
If the conflict candidate file name from the top of the stack is not a prefix of the current candiate directory then we can discard it as no matching directory can come up later. But we are not done checking the candidate directory -- the stack might still hold a matching file name, so stay in the loop and check the next candidate file name. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-21t1450: demonstrate undetected in-tree d/f conflictLibravatar René Scharfe1-0/+1
Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-21t1450: increase test coverage of in-tree d/f detectionLibravatar René Scharfe1-15/+27
Exercise the case of putting a conflict candidate file name back on the stack because a matching directory might yet come up later. Do that by factoring out the test code into a function to allow for more concise notation in the form of parameters indicating names of trees (with trailing slash) and blobs (without trailing slash) in no particular order (they are sorted by git mktree). Then add the new test case as a second function call. Fix a typo in the test title while at it ("dublicate"). Reported-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-21t2060: add a test for switch with --orphan and --discard-changesLibravatar brian m. carlson1-0/+8
We have several code paths in the checkout code which are traversed only in this case, due to switch having different defaults from checkout. Let's add a test that the combination of options works and produces the expected behavior. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-18t4210: detect REG_ILLSEQ dynamically and skip affected testsLibravatar Carlo Marcelo Arenas Belón2-24/+59
7187c7bbb8 (t4210: skip i18n tests that don't work on FreeBSD, 2019-11-27) adds a REG_ILLSEQ prerequisite, and to do that copies the common branch in test-lib and expands it to include it in a special case for FreeBSD. Instead; test for it using a previously added extension to test-tool and use that, together with a function that identifies when regcomp/regexec will be called with broken patterns to avoid any test that would otherwise rely on undefined behaviour. The description of the first test which wasn't accurate has been corrected, and the test rearranged for clarity, including a helper function that avoids overly long lines. Only the affected engines will have their tests suppressed, also including "fixed" if the PCRE optimization that uses LIBPCRE2 since b65abcafc7 (grep: use PCRE v2 for optimized fixed-string search, 2019-07-01) is not available. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>