summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2021-02-05Merge branch 'jk/forbid-lf-in-git-url' into maintLibravatar Junio C Hamano2-0/+20
Newline characters in the host and path part of git:// URL are now forbidden. * jk/forbid-lf-in-git-url: fsck: reject .gitmodules git:// urls with newlines git_connect_git(): forbid newlines in host and path
2021-02-05Merge branch 'ad/t4129-setfacl-target-fix' into maintLibravatar Junio C Hamano1-1/+1
Test fix. * ad/t4129-setfacl-target-fix: t4129: fix setfacl-related permissions failure
2021-02-05Merge branch 'jk/t5516-deflake' into maintLibravatar Junio C Hamano1-1/+3
Test fix. * jk/t5516-deflake: t5516: loosen "not our ref" error check
2021-02-05Merge branch 'pb/mergetool-tool-help-fix' into maintLibravatar Junio C Hamano1-0/+11
Fix 2.29 regression where "git mergetool --tool-help" fails to list all the available tools. * pb/mergetool-tool-help-fix: mergetool--lib: fix '--tool-help' to correctly show available tools
2021-02-05Merge branch 'ds/for-each-repo-noopfix' into maintLibravatar Junio C Hamano1-0/+6
"git for-each-repo --config=<var> <cmd>" should not run <cmd> for any repository when the configuration variable <var> is not defined even once. * ds/for-each-repo-noopfix: for-each-repo: do nothing on empty config
2021-02-05Merge branch 'mt/t4129-with-setgid-dir' into maintLibravatar Junio C Hamano1-2/+7
Some tests expect that "ls -l" output has either '-' or 'x' for group executable bit, but setgid bit can be inherited from parent directory and make these fields 'S' or 's' instead, causing test failures. * mt/t4129-with-setgid-dir: t4129: don't fail if setgid is set in the test directory
2021-02-05Merge branch 'en/stash-apply-sparse-checkout' into maintLibravatar Junio C Hamano2-8/+96
"git stash" did not work well in a sparsely checked out working tree. * en/stash-apply-sparse-checkout: stash: fix stash application in sparse-checkouts stash: remove unnecessary process forking t7012: add a testcase demonstrating stash apply bugs in sparse checkouts
2021-02-05Merge branch 'nk/perf-fsmonitor-cleanup' into maintLibravatar Junio C Hamano1-1/+6
Test fix. * nk/perf-fsmonitor-cleanup: p7519: allow running without watchman prereq
2021-02-05Merge branch 'pk/subsub-fetch-fix-take-2' into maintLibravatar Junio C Hamano1-0/+117
"git fetch --recurse-submodules" fix (second attempt). * pk/subsub-fetch-fix-take-2: submodules: fix of regression on fetching of non-init subsub-repo
2021-01-09t5516: loosen "not our ref" error checkLibravatar Jeff King1-1/+3
Commit 014ade7484 (upload-pack: send ERR packet for non-tip objects, 2019-04-13) added a test that greps the output of a failed fetch to make sure that upload-pack sent us the ERR packet we expected. But checking this is racy; despite the argument in that commit, the client may still be sending a "done" line after the server exits, causing it to die() on a failed write() and never see the ERR packet at all. This fails quite rarely on Linux, but more often on macOS. However, it can be triggered reliably with: diff --git a/fetch-pack.c b/fetch-pack.c index 876f90c759..cf40de9092 100644 --- a/fetch-pack.c +++ b/fetch-pack.c @@ -489,6 +489,7 @@ static int find_common(struct fetch_negotiator *negotiator, done: trace2_region_leave("fetch-pack", "negotiation_v0_v1", the_repository); if (!got_ready || !no_done) { + sleep(1); packet_buf_write(&req_buf, "done\n"); send_request(args, fd[1], &req_buf); } This is a real user-visible race that it would be nice to fix, but it's tricky to do so: the client would have to speculatively try to read an ERR packet after hitting a write() error. And at least for this error, it's specific to v0 (since v2 does not enforce reachability at all). So let's loosen the test to avoid annoying racy failures. If we eventually do the read-after-failed-write thing, we can tighten it. And if not, v0 will grow increasingly obsolete as servers support v2, so the utility of this test will decrease over time anyway. Note that we can still check stderr to make sure upload-pack bailed for the reason we expected. It writes a similar message to stderr, and because the server side is just another process connected by pipes, we'll reliably see it. This would not be the case for git://, or for ssh servers that do not relay stderr (e.g., GitHub's custom endpoint does not). Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-09t4129: fix setfacl-related permissions failureLibravatar Adam Dinwoodie1-1/+1
When running this test in Cygwin, it's necessary to remove the inherited access control lists from the Git working directory in order for later permissions tests to work as expected. As such, fix an error in the test script so that the ACLs are set for the working directory, not a nonexistent subdirectory. Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org> Reviewed-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-07for-each-repo: do nothing on empty configLibravatar Derrick Stolee1-0/+6
'git for-each-repo --config=X' should return success without calling any subcommands when the config key 'X' has no value. The current implementation instead segfaults. A user could run into this issue if they used 'git maintenance start' to initialize their cron schedule using 'git for-each-repo --config=maintenance.repo ...' but then using 'git maintenance unregister' to remove the config option. (Note: 'git maintenance stop' would remove the config _and_ remove the cron schedule.) Add a simple test to ensure this works. Use 'git help --no-such-option' as the potential subcommand to ensure that we will hit a failure if the subcommand is ever run. Reported-by: Andreas Bühmann <dev@uuml.de> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-07fsck: reject .gitmodules git:// urls with newlinesLibravatar Jeff King1-0/+15
The previous commit taught the clone/fetch client side to reject a git:// URL with a newline in it. Let's also catch these when fscking a .gitmodules file, which will give an earlier warning. Note that it would be simpler to just complain about newline in _any_ URL, but an earlier tightening for http/ftp made sure we kept allowing newlines for unknown protocols (and this is covered in the tests). So we'll stick to that precedent. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-07git_connect_git(): forbid newlines in host and pathLibravatar Jeff King1-0/+5
When we connect to a git:// server, we send an initial request that looks something like: 002dgit-upload-pack repo.git\0host=example.com If the repo path contains a newline, then it's included literally, and we get: 002egit-upload-pack repo .git\0host=example.com This works fine if you really do have a newline in your repository name; the server side uses the pktline framing to parse the string, not newlines. However, there are many _other_ protocols in the wild that do parse on newlines, such as HTTP. So a carefully constructed git:// URL can actually turn into a valid HTTP request. For example: git://localhost:1234/%0d%0a%0d%0aGET%20/%20HTTP/1.1 %0d%0aHost:localhost%0d%0a%0d%0a becomes: 0050git-upload-pack / GET / HTTP/1.1 Host:localhost host=localhost:1234 on the wire. Again, this isn't a problem for a real Git server, but it does mean that feeding a malicious URL to Git (e.g., through a submodule) can cause it to make unexpected cross-protocol requests. Since repository names with newlines are presumably quite rare (and indeed, we already disallow them in git-over-http), let's just disallow them over this protocol. Hostnames could likewise inject a newline, but this is unlikely a problem in practice; we'd try resolving the hostname with a newline in it, which wouldn't work. Still, it doesn't hurt to err on the side of caution there, since we would not expect them to work in the first place. The ssh and local code paths are unaffected by this patch. In both cases we're trying to run upload-pack via a shell, and will quote the newline so that it makes it intact. An attacker can point an ssh url at an arbitrary port, of course, but unless there's an actual ssh server there, we'd never get as far as sending our shell command anyway. We _could_ similarly restrict newlines in those protocols out of caution, but there seems little benefit to doing so. The new test here is run alongside the git-daemon tests, which cover the same protocol, but it shouldn't actually contact the daemon at all. In theory we could make the test more robust by setting up an actual repository with a newline in it (so that our clone would succeed if our new check didn't kick in). But a repo directory with newline in it is likely not portable across all filesystems. Likewise, we could check git-daemon's log that it was not contacted at all, but we do not currently record the log (and anyway, it would make the test racy with the daemon's log write). We'll just check the client-side stderr to make sure we hit the expected code path. Reported-by: Harold Kim <h.kim@flatt.tech> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-06mergetool--lib: fix '--tool-help' to correctly show available toolsLibravatar Philippe Blain1-0/+11
Commit 83bbf9b92e (mergetool--lib: improve support for vimdiff-style tool variants, 2020-07-29) introduced a regression in the output of `git mergetool --tool-help` and `git difftool --tool-help` [1]. In function 'show_tool_names' in git-mergetool--lib.sh, we loop over the supported mergetools and their variants and accumulate them in the variable 'variants', separating them with a literal '\n'. The code then uses 'echo $variants' to turn these '\n' into newlines, but this behaviour is not portable, it just happens to work in some shells, like dash(1)'s 'echo' builtin. For shells in which 'echo' does not turn '\n' into newlines, the end result is that the only tools that are shown are the existing variants (except the last variant alphabetically), since the variants are separated by actual newlines in '$variants' because of the several 'echo' calls in mergetools/{bc,vimdiff}::list_tool_variants. Fix this bug by embedding an actual line feed into `variants` in show_tool_names(). While at it, replace `sort | uniq` by `sort -u`. To prevent future regressions, add a simple test that checks that a few known tools are correctly shown (let's avoid counting the total number of tools to lessen the maintenance burden when new tools are added or if '--tool-help' learns additional logic, like hiding tools depending on the current platform). [1] https://lore.kernel.org/git/CADtb9DyozjgAsdFYL8fFBEWmq7iz4=prZYVUdH9W-J5CKVS4OA@mail.gmail.com/ Reported-by: Philippe Blain <levraiphilippeblain@gmail.com> Based-on-patch-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Philippe Blain <levraiphilippeblain@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>
2021-01-06p7519: allow running without watchman prereqLibravatar Taylor Blau1-1/+6
p7519 measures the performance of the fsmonitor code. To do this, it uses the installed copy of Watchman. If Watchman isn't installed, a noop integration script is installed in its place. When in the latter mode, it is expected that the script should not write a "last update token": in fact, it doesn't write anything at all since the script is blank. Commit 33226af42b (t/perf/fsmonitor: improve error message if typoing hook name, 2020-10-26) made sure that running 'git update-index --fsmonitor' did not write anything to stderr, but this is not the case when using the empty Watchman script, since Git will complain that: $ which watchman watchman not found $ cat .git/hooks/fsmonitor-empty $ git -c core.fsmonitor=.git/hooks/fsmonitor-empty update-index --fsmonitor warning: Empty last update token. Prior to 33226af42b, the output wasn't checked at all, which allowed this noop mode to work. But, 33226af42b breaks p7519 when running it without a 'watchman(1)' on your system. Handle this by only checking that the stderr is empty only when running with a real watchman executable. Otherwise, assert that the error message is the expected one when running in the noop mode. Signed-off-by: Taylor Blau <me@ttaylorr.com> Acked-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-23Merge branch 'nk/refspecs-negative-fix'Libravatar Junio C Hamano1-0/+51
Hotfix for recent regression. * nk/refspecs-negative-fix: negative-refspec: improve comment on query_matches_negative_refspec negative-refspec: fix segfault on : refspec
2020-12-23Merge branch 'ma/maintenance-crontab-fix'Libravatar Junio C Hamano1-0/+16
Hotfix for a topic of this cycle. * ma/maintenance-crontab-fix: t7900-maintenance: test for magic markers gc: fix handling of crontab magic markers git-maintenance.txt: add missing word
2020-12-23Merge branch 'dl/checkout-p-merge-base'Libravatar Junio C Hamano1-0/+5
Fix to a regression introduced during this cycle. * dl/checkout-p-merge-base: checkout -p: handle tree arguments correctly again
2020-12-23Merge branch 'js/no-more-prepare-for-main-in-test'Libravatar Junio C Hamano11-619/+621
Test coverage fix. * js/no-more-prepare-for-main-in-test: tests: drop the `PREPARE_FOR_MAIN_BRANCH` prereq t9902: use `main` as initial branch name t6302: use `main` as initial branch name t5703: use `main` as initial branch name t5510: use `main` as initial branch name t5505: finalize transitioning to using the branch name `main` t3205: finalize transitioning to using the branch name `main` t3203: complete the transition to using the branch name `main` t3201: finalize transitioning to using the branch name `main` t3200: finish transitioning to the initial branch name `main` t1400: use `main` as initial branch name
2020-12-23Merge branch 'jx/pack-redundant-on-single-pack'Libravatar Junio C Hamano1-4/+33
"git pack-redandant" when there is only one packfile used to crash, which has been corrected. * jx/pack-redundant-on-single-pack: pack-redundant: fix crash when one packfile in repo
2020-12-21negative-refspec: fix segfault on : refspecLibravatar Nipunn Koorapati1-0/+51
The logic added to check for negative pathspec match by c0192df630 (refspec: add support for negative refspecs, 2020-09-30) looks at refspec->src assuming it is never NULL, however when remote.origin.push is set to ":", then refspec->src is NULL, causing a segfault within strcmp. Tell git to handle matching refspec by adding the needle to the set of positively matched refspecs, since matching ":" refspecs match anything as src. Add test for matching refspec pushes fetch-negative-refspec both individually and in combination with a negative refspec. Signed-off-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-21t7900-maintenance: test for magic markersLibravatar Martin Ågren1-0/+9
When we insert our "BEGIN" and "END" markers into the cron table, it's so that a Git version from many years into the future would be able to identify this region in the cron table. Let's add a test to make sure that these markers don't ever change. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Acked-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-21gc: fix handling of crontab magic markersLibravatar Martin Ågren1-0/+7
On `git maintenance start`, we add a few entries to the user's cron table. We wrap our entries using two magic markers, "# BEGIN GIT MAINTENANCE SCHEDULE" and "# END GIT MAINTENANCE SCHEDULE". At a later `git maintenance stop`, we will go through the table and remove these lines. Or rather, we will remove the "BEGIN" marker, the "END" marker and everything between them. Alas, we have a bug in how we detect the "END" marker: we don't. As we loop through all the lines of the crontab, if we are in the "old region", i.e., the region we're aiming to remove, we make an early `continue` and don't get as far as checking for the "END" marker. Thus, once we've seen our "BEGIN", we remove everything until the end of the file. Rewrite the logic for identifying these markers. There are four cases that are mutually exclusive: The current line starts a region or it ends it, or it's firmly within the region, or it's outside of it (and should be printed). Signed-off-by: Martin Ågren <martin.agren@gmail.com> Acked-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-21checkout -p: handle tree arguments correctly againLibravatar Johannes Schindelin1-0/+5
This fixes a segmentation fault. The bug is caused by dereferencing `new_branch_info->commit` when it is `NULL`, which is the case when the tree-ish argument is actually a tree, not a commit-ish. This was introduced in 5602b500c3c (builtin/checkout: fix `git checkout -p HEAD...` bug, 2020-10-07), where we tried to ensure that the special tree-ish `HEAD...` is handled correctly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-18Merge branch 'jc/diff-I-status-fix'Libravatar Junio C Hamano1-0/+24
"git diff -I<pattern> -exit-code" should exit with 0 status when all the changes match the ignored pattern, but it didn't. * jc/diff-I-status-fix: diff: correct interaction between --exit-code and -I<pattern>
2020-12-18Merge branch 'es/perf-export-fix'Libravatar Junio C Hamano1-2/+7
Dev-support fix for BSD. * es/perf-export-fix: t/perf: fix test_export() failure with BSD `sed`
2020-12-18Merge branch 'js/init-defaultbranch-advice'Libravatar Junio C Hamano3-3/+20
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-17Merge branch 'js/t7064-master-to-initial'Libravatar Junio C Hamano1-51/+52
Test update. * js/t7064-master-to-initial: t7064: avoid relying on a specific default branch name
2020-12-17Merge branch 'js/t6300-hardcode-main'Libravatar Junio C Hamano1-88/+90
Test update. * js/t6300-hardcode-main: t6300: avoid using the default name of the initial branch
2020-12-17Merge branch 'jk/oid-array-cleanup'Libravatar Junio C Hamano1-3/+6
Code clean-up. * jk/oid-array-cleanup: commit-graph: use size_t for array allocation and indexing commit-graph: replace packed_oid_list with oid_array commit-graph: drop count_distinct_commits() function oid-array: provide a for-loop iterator oid-array: make sort function public cache.h: move hash/oid functions to hash.h t0064: make duplicate tests more robust t0064: drop sha1 mention from filename oid-array.h: drop sha1 mention from header guard
2020-12-17Merge branch 'tb/partial-clone-filters-fix'Libravatar Junio C Hamano1-1/+9
Fix potential server side resource deallocation issues when responding to a partial clone request. * tb/partial-clone-filters-fix: upload-pack.c: don't free allowed_filters util pointers builtin/clone.c: don't ignore transport_fetch_refs() errors
2020-12-17Merge branch 'js/t7900-protect-pwd-in-config-get'Libravatar Junio C Hamano1-2/+2
Hotfix for test breakage. * js/t7900-protect-pwd-in-config-get: t7900: use --fixed-value in git-maintenance tests
2020-12-16pack-redundant: fix crash when one packfile in repoLibravatar Jiang Xin1-4/+33
Command `git pack-redundant --all` will crash if there is only one packfile in the repository. This is because, if there is only one packfile in local_packs, `cmp_local_packs` will do nothing and will leave `pl->unique_objects` as uninitialized. Also add testcases for repository with no packfile and one packfile in t5323. Reported-by: Daniel C. Klauer <daniel.c.klauer@web.de> Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-16tests: drop the `PREPARE_FOR_MAIN_BRANCH` prereqLibravatar Johannes Schindelin1-8/+0
We no longer use it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-16t9902: use `main` as initial branch nameLibravatar Johannes Schindelin1-154/+155
In 8164360fc86 (t9902: prepare a test for the upcoming default branch name, 2020-10-23), we started adjusting this test script for the default initial branch name changing to `main`. However, there is no need to wait for that: let's adjust the test script to stop relying on a specific initial branch name by setting it explicitly. This allows us to drop the `PREPARE_FOR_MAIN_BRANCH` prereq from one test case. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-16t6302: use `main` as initial branch nameLibravatar Johannes Schindelin1-29/+30
In 66713e84e71 (tests: prepare aligned mentions of the default branch name, 2020-10-23), we started adjusting this test script for the default initial branch name changing to `main`. However, there is no need to wait for that: let's adjust the test script to stop relying on a specific initial branch name by setting it explicitly. This allows us to drop the `PREPARE_FOR_MAIN_BRANCH` prereq from six test cases. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-16t5703: use `main` as initial branch nameLibravatar Johannes Schindelin1-32/+33
In 97cf8d50b59 (t5703: adjust a test case for the upcoming default branch name, 2020-10-23), we prepared this test script for a world when the default initial branch name would be `main`. However, there is no need to wait for that: let's adjust the test script to stop relying on a specific initial branch name by setting it explicitly. This allows us to drop the `PREPARE_FOR_MAIN_BRANCH` prereq from one test case. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-16t5510: use `main` as initial branch nameLibravatar Johannes Schindelin1-83/+85
In 66713e84e71 (tests: prepare aligned mentions of the default branch name, 2020-10-23), we prepared this test script for a time when the default initial branch name would be `main`. However, there is no need to wait for that: let's adjust the test script to stop relying on a specific initial branch name by setting it explicitly. This allows us to drop the `PREPARE_FOR_MAIN_BRANCH` prereq from two test cases. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-16t5505: finalize transitioning to using the branch name `main`Libravatar Johannes Schindelin1-78/+78
In 66713e84e71 (tests: prepare aligned mentions of the default branch name, 2020-10-23), we started that transition, trying to prepare for a time when `git init` would use that name for the initial branch. Even if that time has not arrived, we can complete the transition by making the test script independent of the default branch name. This also allows us to drop the `PREPARE_FOR_MAIN_BRANCH` prereq from four test cases. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-16t3205: finalize transitioning to using the branch name `main`Libravatar Johannes Schindelin1-4/+5
In 66713e84e71 (tests: prepare aligned mentions of the default branch name, 2020-10-23), we started that transition, trying to prepare for a time when `git init` would use that name for the initial branch. Even if that time has not arrived, we can complete the transition by making the test script independent of the default branch name. This also allows us to drop the `PREPARE_FOR_MAIN_BRANCH` prereq from one test case. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-16t3203: complete the transition to using the branch name `main`Libravatar Johannes Schindelin1-21/+22
In 66713e84e71 (tests: prepare aligned mentions of the default branch name, 2020-10-23), we started that transition, trying to prepare for a time when `git init` would use that name for the initial branch. Even if that time has not arrived, we can complete the transition by making the test script independent of the default branch name. This also allows us to drop the `PREPARE_FOR_MAIN_BRANCH` prereq from one test case. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-16t3201: finalize transitioning to using the branch name `main`Libravatar Johannes Schindelin1-41/+42
In 66713e84e71 (tests: prepare aligned mentions of the default branch name, 2020-10-23), we started that transition, trying to prepare for a time when `git init` would use that name for the initial branch. Even if that time has not arrived, we can complete the transition by making the test script independent of the default branch name. This also allows us to drop the `PREPARE_FOR_MAIN_BRANCH` prereq from one test case. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-16t3200: finish transitioning to the initial branch name `main`Libravatar Johannes Schindelin1-132/+133
In 56300ff356b (t3200: prepare for `main` being shorter than `master`, 2020-10-23) and in 66713e84e71 (tests: prepare aligned mentions of the default branch name, 2020-10-23), we started to prepare t3200 for a new world where `git init` uses the branch name `main` for the initial branch. We do not even have to wait for that new world: we can easily ensure that that branch name is used, independent of the exact name `git init` will give the initial branch, so let's do that. This also lets us remove the `PREPARE_FOR_MAIN_BRANCH` prereq from three test cases in that script. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-16t1400: use `main` as initial branch nameLibravatar Johannes Schindelin1-37/+38
In 3224b0f0bb7 (t1400: prepare for `main` being default branch name, 2020-10-23), we prepared t1400 for a time when the default initial branch name would be `main`. However, there is no need to wait that long: let's adjust the test script to stop relying on a specific initial branch name by setting it explicitly. This allows us to drop the `PREPARE_FOR_MAIN_BRANCH` prereq from two test cases. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-16diff: correct interaction between --exit-code and -I<pattern>Libravatar Junio C Hamano1-0/+24
Just like "git diff -w --exit-code" should exit with 0 when ignoring whitespace differences results in no changes shown, if ignoring certain changes with "git diff -I<pattern> --exit-code" result in an empty patch, we should exit with 0. The test suite did not cover the interaction between "--exit-code" and "-w"; add one while adding a new test for "--exit-code" + "-I". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-16t/perf: fix test_export() failure with BSD `sed`Libravatar Eric Sunshine1-2/+7
test_perf() runs each test in its own subshell which makes it difficult to persist variables between tests. test_export() addresses this shortcoming by grabbing the values of specified variables after a test runs but before the subshell exits, and writes those values to a file which is loaded into the environment of subsequent tests. To grab the values to be persisted, test_export() pipes the output of the shell's builtin `set` command through `sed` which plucks them out using a regular expression along the lines of `s/^(var1|var2)/.../p`. Unfortunately, though, this use of alternation is not portable. For instance, BSD-lineage `sed` (including macOS `sed`) does not support it in the default "basic regular expression" mode (BRE). It may be possible to enable "extended regular expression" mode (ERE) in some cases with `sed -E`, however, `-E` is neither portable nor part of POSIX. Fortunately, alternation is unnecessary in this case and can easily be avoided, so replace it with a series of simple expressions such as `s/^var1/.../p;s/^var2/.../p`. While at it, tighten the expressions so they match the variable names exactly rather than matching prefixes (i.e. use `s/^var1=/.../p`). If the requirements of test_export() become more complex in the future, then an alternative would be to replace `sed` with `perl` which supports alternation on all platforms, however, the simple elimination of alternation via multiple `sed` expressions suffices for the present. Reported-by: Sangeeta <sangunb09@gmail.com> Diagnosed-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-14Merge branch 'js/t5526-with-no-particular-primary-branch-name'Libravatar Junio C Hamano1-40/+43
Test update. * js/t5526-with-no-particular-primary-branch-name: t5526: drop the prereq expecting the default branch name `main` t5526: avoid depending on a specific default branch name
2020-12-14Merge branch 'jk/check-config-parsing-error-in-upload-pack'Libravatar Junio C Hamano1-0/+8
Tighten error checking in the codepath that responds to "git fetch". * jk/check-config-parsing-error-in-upload-pack: upload-pack: propagate return value from object filter config callback