summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2019-09-06test-read-cache: drop namelen variableLibravatar Jeff King1-3/+2
Early in the function we set "namelen = strlen(name)" if "name" is non-NULL. Later, we use "namelen" only if "name" is non-NULL. However, it's hard to immediately see this, and it seems to confuse gcc 9.2.1 (with "-flto" interestingly, though all of the involved logic is in inline functions; it also triggers when building with ASan). Let's simplify the code and remove the variable entirely. There's only one use of namelen anyway, so we can just call strlen() then. It's true this is in a loop, so we might execute strlen() more often. But: - this is test code that only ever loops twice in our test suite (we do loop 1000 times in a t/perf test, but without using this option). - a decent compiler ought to be able to hoist that out of the loop anyway (though I wouldn't count on gcc 9.2.1 doing so!) Reported-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-22Merge branch 'jk/perf-no-dups'Libravatar Junio C Hamano1-0/+0
Test & perf scripts must use unique numeric prefix, but a pair shared the same number, which is fixed here. * jk/perf-no-dups: t/perf: rename duplicate-numbered test script
2019-08-22Merge branch 'sg/show-failed-test-names'Libravatar Junio C Hamano3-12/+14
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-22Merge branch 'sg/commit-graph-validate'Libravatar Junio C Hamano1-3/+11
The code to write commit-graph over given commit object names has been made a bit more robust. * sg/commit-graph-validate: commit-graph: error out on invalid commit oids in 'write --stdin-commits' commit-graph: turn a group of write-related macro flags into an enum t5318-commit-graph: use 'test_expect_code'
2019-08-22Merge branch 'vn/restore-empty-ita-corner-case-fix'Libravatar Junio C Hamano2-0/+22
"git checkout" and "git restore" to re-populate the index from a tree-ish (typically HEAD) did not work correctly for a path that was removed and then added again with the intent-to-add bit, when the corresponding working tree file was empty. This has been corrected. * vn/restore-empty-ita-corner-case-fix: restore: add test for deleted ita files checkout.c: unstage empty deleted ita files
2019-08-22Merge branch 'sg/do-not-skip-non-httpd-tests'Libravatar Junio C Hamano10-122/+153
Test fix. * sg/do-not-skip-non-httpd-tests: t: warn against adding non-httpd-specific tests after sourcing 'lib-httpd' t5703: run all non-httpd-specific tests before sourcing 'lib-httpd.sh' t5510-fetch: run non-httpd-specific test before sourcing 'lib-httpd.sh'
2019-08-22Merge branch 'sg/t5510-test-i18ngrep-fix'Libravatar Junio C Hamano1-1/+1
Test fix. * sg/t5510-test-i18ngrep-fix: t5510-fetch: fix negated 'test_i18ngrep' invocation
2019-08-22Merge branch 'mt/grep-submodules-working-tree'Libravatar Junio C Hamano1-0/+21
"git grep --recurse-submodules" that looks at the working tree files looked at the contents in the index in submodules, instead of files in the working tree. * mt/grep-submodules-working-tree: grep: fix worktree case in submodules
2019-08-12t/perf: rename duplicate-numbered test scriptLibravatar Jeff King1-0/+0
There are two perf scripts numbered p5600, but with otherwise different names ("clone-reference" versus "partial-clone"). We store timing results in files named after the whole script, so internally we don't get confused between the two. But "aggregate.perl" just prints the test number for each result, giving multiple entries for "5600.3". It also makes it impossible to skip one test but not the other with GIT_SKIP_TESTS. Let's renumber the one that appeared later (by date -- the source of the problem is that the two were developed on independent branches). For the non-perf test suite, our test-lint rule would have complained about this when the two were merged, but t/perf never learned that trick. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-09Merge branch 'bc/hash-independent-tests-part-4'Libravatar Junio C Hamano2-9/+8
Test fix. * bc/hash-independent-tests-part-4: t0000: reword comments for "local" test t: decrease nesting in test_oid_to_path
2019-08-09Merge branch 'mt/dir-iterator-updates'Libravatar Junio C Hamano1-3/+1
Leakfix. * mt/dir-iterator-updates: test-dir-iterator: use path argument directly dir-iterator: release strbuf after use
2019-08-08Merge branch 'en/disable-dir-rename-in-recursive-merge'Libravatar Junio C Hamano1-0/+111
"merge-recursive" hit a BUG() when building a virtual merge base detected a directory rename. * en/disable-dir-rename-in-recursive-merge: merge-recursive: avoid directory rename detection in recursive case
2019-08-08t0000: reword comments for "local" testLibravatar Jeff King1-8/+6
Commit 01d3a526ad (t0000: check whether the shell supports the "local" keyword, 2017-10-26) added a test to gather data on whether people run the test suite with shells that don't support "local". After almost two years, nobody has complained, and several other uses have cropped up in test-lib-functions.sh. Let's declare it acceptable to use. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
2019-08-07test-dir-iterator: use path argument directlyLibravatar René Scharfe1-3/+1
Avoid allocating and leaking a strbuf for holding a verbatim copy of the path argument and pass the latter directly to dir_iterator_begin() instead. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-06merge-recursive: avoid directory rename detection in recursive caseLibravatar Elijah Newren1-0/+111
Ever since commit 8c8e5bd6eb33 ("merge-recursive: switch directory rename detection default", 2019-04-05), the default handling with directory rename detection was to report a conflict and leave unstaged entries in the index. However, when creating a virtual merge base in the recursive case, we absolutely need a tree, and the only way a tree can be written is if we have no unstaged entries -- otherwise we hit a BUG(). There are a few fixes possible here which at least fix the BUG(), but none of them seem optimal for other reasons; see the comments with the new testcase 13e in t6043 for details (which testcase triggered a BUG() prior to this patch). As such, just opt for a very conservative and simple choice that is still relatively reasonable: have the recursive case treat 'conflict' as 'false' for opt->detect_directory_renames. Reported-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-05tests: show the test name and number at the start of verbose outputLibravatar SZEDER Gábor3-6/+8
The verbose output of every test looks something like this: expecting success: echo content >file && git add file && git commit -m "add file" [master (root-commit) d1fbfbd] add file Author: A U Thor <author@example.com> 1 file changed, 1 insertion(+) create mode 100644 file ok 1 - commit works i.e. first an "expecting success" (or "checking known breakage") line followed by the commands to be executed, then the output of those comamnds, and finally an "ok"/"not ok" line containing the test name. Note that the test's name is only shown at the very end. With '-x' tracing enabled and/or in longer tests the verbose output might be several screenfulls long, making it harder than necessary to find where the output of the test with a given name starts (especially when the outputs to different file descriptors are racing, and the "expecting success"/command block arrives earlier than the "ok" line of the previous test). Print the test name at the start of the test's verbose output, i.e. at the end of the "expecting success" and "checking known breakage" lines, to make the start of a particular test a bit easier to recognize. Also print the test script and test case numbers, to help those poor souls who regularly have to scan through the combined verbose output of several test scripts. So the dummy test above would start like this: expecting success of 9999.1 'commit works': echo content >file && [...] Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-05t0000-basic: use realistic test script names in the verbose testsLibravatar SZEDER Gábor1-6/+6
Our test scripts are named something like 't1234-command.sh', but the script names used in 't0000-basic.sh' don't follow this naming convention. Normally this doesn't matter, because the test scripts themselves don't care how they are called. However, the next patch will start to include the test number in the test's verbose output, so the test script's name will matter in the two tests checking the verbose output. Update the tests 'test --verbose' and 'test --verbose-only' to follow out test script naming convention. Leave the other tests in 't0000' unchanged: changing the names of their test scripts would be only pointless code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-05commit-graph: fix bug around octopus mergesLibravatar Derrick Stolee1-1/+3
In 1771be90 "commit-graph: merge commit-graph chains" (2019-06-18), the method sort_and_scan_merged_commits() was added to merge the commit lists of two commit-graph files in the incremental format. Unfortunately, there was an off-by-one error in that method around incrementing num_extra_edges, which leads to an incorrect offset for the base graph chunk. When we store an octopus merge in the commit-graph file, we store the first parent in the normal place, but use the second parent position to point into the "extra edges" chunk where the remaining parents exist. This means we should be adding "num_parents - 1" edges to this list, not "num_parents - 2". That is the basic error. The reason this was not caught in the test suite is more subtle. In 5324-split-commit-graph.sh, we test creating an octopus merge and adding it to the tip of a commit-graph chain, then verify the result. This _should_ have caught the problem, except that when we load the commit-graph files we were overly careful to not fail when the commit-graph chain does not match. This care was on purpose to avoid race conditions as one process reads the chain and another process modifies it. In such a case, the reading process outputs the following message to stderr: warning: commit-graph chain does not match These warnings are output in the test suite, but ignored. By checking the stderr of `git commit-graph verify` to include the expected progress output, it will now catch this error. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-05commit-graph: error out on invalid commit oids in 'write --stdin-commits'Libravatar SZEDER Gábor1-1/+10
While 'git commit-graph write --stdin-commits' expects commit object ids as input, it accepts and silently skips over any invalid commit object ids, and still exits with success: # nonsense $ echo not-a-commit-oid | git commit-graph write --stdin-commits $ echo $? 0 # sometimes I forgot that refs are not good... $ echo HEAD | git commit-graph write --stdin-commits $ echo $? 0 # valid tree OID, but not a commit OID $ git rev-parse HEAD^{tree} | git commit-graph write --stdin-commits $ echo $? 0 $ ls -l .git/objects/info/commit-graph ls: cannot access '.git/objects/info/commit-graph': No such file or directory Check that all input records are indeed valid commit object ids and return with error otherwise, the same way '--stdin-packs' handles invalid input; see e103f7276f (commit-graph: return with errors during write, 2019-06-12). Note that it should only return with error when encountering an invalid commit object id coming from standard input. However, '--reachable' uses the same code path to process object ids pointed to by all refs, and that includes tag object ids as well, which should still be skipped over. Therefore add a new flag to 'enum commit_graph_write_flags' and a corresponding field to 'struct write_commit_graph_context', so we can differentiate between those two cases. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Acked-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-05t5318-commit-graph: use 'test_expect_code'Libravatar SZEDER Gábor1-2/+1
In 't5318-commit-graph.sh' the test 'close with correct error on bad input' manually verifies the exit code of a 'git commit-graph write' command. Use 'test_expect_code' instead. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Acked-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-02Merge branch 'jc/log-mailmap-flip-defaults'Libravatar Junio C Hamano2-2/+33
Hotfix for making "git log" use the mailmap by default. * jc/log-mailmap-flip-defaults: log: really flip the --mailmap default log: flip the --mailmap default unconditionally
2019-08-02Merge branch 'js/early-config-with-onbranch'Libravatar Junio C Hamano1-0/+5
The recently added [includeif "onbranch:branch"] feature does not work well with an early config mechanism, as it attempts to find out what branch we are on before we even haven't located the git repository. The inclusion during early config scan is ignored to work around this issue. * js/early-config-with-onbranch: config: work around bug with includeif:onbranch and early config
2019-08-02restore: add test for deleted ita filesLibravatar Varun Naik1-0/+11
`git restore --staged` uses the same machinery as `git checkout HEAD`, so there should be a similar test case for "restore" as the existing test case for "checkout" with deleted ita files. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Varun Naik <vcnaik94@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-02checkout.c: unstage empty deleted ita filesLibravatar Varun Naik1-0/+11
It is possible to delete a committed file from the index and then add it as intent-to-add. After `git checkout HEAD <pathspec>`, the file should be identical in the index and HEAD. The command already works correctly if the file has contents in HEAD. This patch provides the desired behavior even when the file is empty in HEAD. `git checkout HEAD <pathspec>` calls tree.c:read_tree_1(), with fn pointing to checkout.c:update_some(). update_some() creates a new cache entry but discards it when its mode and oid match those of the old entry. A cache entry for an ita file and a cache entry for an empty file have the same oid. Therefore, an empty deleted ita file previously passed both of these checks, and the new entry was discarded, so the file remained unchanged in the index. After this fix, if the file is marked as ita in the cache, then we avoid discarding the new entry and add the new entry to the cache instead. This change should not affect newly added ita files. For those, inside tree.c:read_tree_1(), tree_entry_interesting() returns entry_not_interesting, so fn is never called. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Varun Naik <vcnaik94@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-02log: really flip the --mailmap defaultLibravatar Junio C Hamano1-0/+33
Update the docs, test the interaction between the new default, configuration and command line option, in addition to actually flipping the default. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-02t: warn against adding non-httpd-specific tests after sourcing 'lib-httpd'Libravatar SZEDER Gábor8-0/+24
We have a couple of test scripts that are not completely httpd-specific, but do run a few httpd-specific tests at the end. These test scripts source 'lib-httpd.sh' somewhere mid-script, which then skips all the rest of the test script if the dependencies for running httpd tests are not fulfilled. As the previous two patches in this series show, already on two occasions non-httpd-specific tests were appended at the end of such test scripts, and, consequently, they were skipped as well when httpd tests couldn't be run. Add a comment at the end of these test scripts to warn against adding non-httpd-specific tests at the end, in the hope that they will help prevent similar issues in the future. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-01t5703: run all non-httpd-specific tests before sourcing 'lib-httpd.sh'Libravatar SZEDER Gábor1-100/+104
't5703-upload-pack-ref-in-want.sh' sources 'lib-httpd.sh' near the end to run a couple of httpd-specific tests, but 'lib-httpd.sh' skips all the rest of the test script if the dependencies for running httpd tests are not fulfilled. However, the last six tests in 't5703' are not httpd-specific, but they are skipped as well when httpd tests can't be run. Move these six tests earlier in the test script, before 'lib-httpd.sh' is sourced, so they will be run even when httpd tests aren't. Note that this is not merely a pure code movement, because the setup test case for the httpd tests needed an additional 'rm -rf "$LOCAL_PRISTINE"' to clean up a directory left behind by the moved non-httpd-specific tests. Also add a comment at the end of this test script to warn against adding non-httpd-specific tests at the end, in the hope that it will help prevent similar issues in the future. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-01t5510-fetch: run non-httpd-specific test before sourcing 'lib-httpd.sh'Libravatar SZEDER Gábor1-22/+25
't5510-fetch.sh' sources 'lib-httpd.sh' near the end to run a httpd-specific test, but 'lib-httpd.sh' skips all the rest of the test script if the dependencies for running httpd tests are not fulfilled. Alas, recently cdbd70c437 (fetch: add --[no-]show-forced-updates argument, 2019-06-18) appended a non-httpd-specific test at the end, and this test is then skipped as well when httpd tests can't be run. Move this new test earlier in the test script, before 'lib-httpd.sh' is sourced, so it will be run even when httpd tests aren't. Also add a comment at the end of this test script to warn against adding non-httpd-specific tests at the end, in the hope that it will help prevent similar issues in the future. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-01Merge branch 'jk/repack-silence-auto-bitmap-warning'Libravatar Junio C Hamano1-1/+14
Squelch unneeded and misleading warnings from "repack" when the command attempts to generate pack bitmaps without explicitly asked for by the user. * jk/repack-silence-auto-bitmap-warning: repack: simplify handling of auto-bitmaps and .keep files repack: silence warnings when auto-enabled bitmaps cannot be built t7700: clean up .keep file in bitmap-writing test
2019-08-01Merge branch 'jk/sort-iter-test-output'Libravatar Junio C Hamano2-33/+55
* jk/sort-iter-test-output: t: sort output of hashmap iteration
2019-08-01Merge branch 'jc/dir-iterator-test-fix'Libravatar Junio C Hamano2-3/+12
* jc/dir-iterator-test-fix: test-dir-iterator: do not assume errno values
2019-08-01Merge branch 'bc/hash-independent-tests-part-4'Libravatar Junio C Hamano11-93/+142
Update to the tests to help SHA-256 transition continues. * bc/hash-independent-tests-part-4: t2203: avoid hard-coded object ID values t1710: make hash independent t1007: remove SHA1 prerequisites t0090: make test pass with SHA-256 t0027: make hash size independent t6030: make test work with SHA-256 t5000: make hash independent t1450: make hash size independent t1410: make hash size independent t: add helper to convert object IDs to paths
2019-08-01log: flip the --mailmap default unconditionallyLibravatar Junio C Hamano1-2/+0
It turns out that being cautious to warn against upcoming default change was an unpopular behaviour, and such a care can easily be defeated by distro packagers to render it ineffective anyway. Just flip the default, with only a mention in the release notes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-31config: work around bug with includeif:onbranch and early configLibravatar Johannes Schindelin1-0/+5
Since 07b2c0eacac (config: learn the "onbranch:" includeIf condition, 2019-06-05), there is a potential catch-22 in the early config path: if the `include.onbranch:` feature is used, Git assumes that the Git directory has been initialized already. However, in the early config code path that is not true. One way to trigger this is to call the following commands in any repository: git config includeif.onbranch:refs/heads/master.path broken git help -a The symptom triggered by the `git help -a` invocation reads like this: BUG: refs.c:1851: attempting to get main_ref_store outside of repository Let's work around this, simply by ignoring the `includeif.onbranch:` setting when parsing the config when the ref store has not been initialized (yet). Technically, there is a way to solve this properly: teach the refs machinery to initialize the ref_store from a given gitdir/commondir pair (which we _do_ have in the early config code path), and then use that in `include_by_branch()`. This, however, is a pretty involved project, and we're already in the feature freeze for Git v2.23.0. Note: when calling above-mentioned two commands _outside_ of any Git worktree (passing the `--global` flag to `git config`, as there is obviously no repository config available), at the point when `include_by_branch()` is called, `the_repository` is `NULL`, therefore we have to be extra careful not to dereference it in that case. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-31repack: simplify handling of auto-bitmaps and .keep filesLibravatar Jeff King1-1/+2
Commit 7328482253 (repack: disable bitmaps-by-default if .keep files exist, 2019-06-29) taught repack to prefer disabling bitmaps to duplicating objects (unless bitmaps were asked for explicitly). But there's an easier way to do this: if we keep passing the --honor-pack-keep flag to pack-objects when auto-enabling bitmaps, then pack-objects already makes the same decision (it will disable bitmaps rather than duplicate). Better still, pack-objects can actually decide to do so based not just on the presence of a .keep file, but on whether that .keep file actually impacts the new pack we're making (so if we're racing with a push or fetch, for example, their temporary .keep file will not block us from generating bitmaps if they haven't yet updated their refs). And because repack uses the --write-bitmap-index-quiet flag, we don't have to worry about pack-objects generating confusing warnings when it does see a .keep file. We can confirm this by tweaking the .keep test to check repack's stderr. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-31repack: silence warnings when auto-enabled bitmaps cannot be builtLibravatar Jeff King1-0/+11
Depending on various config options, a full repack may not be able to build a reachability bitmap index (e.g., if pack.packSizeLimit forces us to write multiple packs). In these cases pack-objects may write a warning to stderr. Since 36eba0323d (repack: enable bitmaps by default on bare repos, 2019-03-14), we may generate these warnings even when the user did not explicitly ask for bitmaps. This has two downsides: - it can be confusing, if they don't know what bitmaps are - a daemonized auto-gc will write this to its log file, and the presence of the warning may suppress further auto-gc (until gc.logExpiry has elapsed) Let's have repack communicate to pack-objects that the choice to turn on bitmaps was not made explicitly by the user, which in turn allows pack-objects to suppress these warnings. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-31t7700: clean up .keep file in bitmap-writing testLibravatar Jeff King1-0/+1
After our test snippet finishes, the .keep file is left in place, making it hard to do further tests of the auto-bitmap-writing code (since it suppresses the feature completely). Let's clean it up. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-31t5510-fetch: fix negated 'test_i18ngrep' invocationLibravatar SZEDER Gábor1-1/+1
The test '--no-show-forced-updates' in 't5510-fetch.sh' added in cdbd70c437 (fetch: add --[no-]show-forced-updates argument, 2019-06-18) runs '! test_i18ngrep ...'. This is wrong, because when running the test with GIT_TEST_GETTEXT_POISON=true, then 'test_i18ngrep' is basically a noop and always returns with success, the leading ! turns that into a failure, which then fails the test. Use 'test_i18ngrep ! ...' instead. This went unnoticed by our GETTEXT_POISON CI builds, because those builds don't run this test case: in those builds we don't install Apache, and this test comes after 't5510' sources 'lib-httpd.sh', which, consequently, skips all the remaining tests, including this one. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-31t: sort output of hashmap iterationLibravatar Jeff King2-33/+55
The iteration order of a hashmap is undefined, and may depend on things like the exact set of items added, or the table has been grown or shrunk. In the case of an oidmap, it even depends on endianness, because we take the oid hash by casting sha1 bytes directly into an unsigned int. Let's sort the test-tool output from any hash iterators. In the case of t0011, this is just future-proofing. But for t0016, it actually fixes a reported failure on the big-endian s390 and nonstop ports. I didn't bother to teach the helper functions to optionally sort output. They are short enough that it's simpler to just repeat them inline for the iteration tests than it is to add a --sort option. Reported-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-30grep: fix worktree case in submodulesLibravatar Matheus Tavares1-0/+21
Running git-grep with --recurse-submodules results in a cached grep for the submodules even when --cached is not used. This makes all modifications in submodules' tracked files be always ignored when grepping. Solve that making git-grep respect the cached option when invoking grep_cache() inside grep_submodule(). Also, add tests to ensure that the desired behavior is performed. Reported-by: Daniel Zaoui <jackdanielz@eyomi.org> Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-30test-dir-iterator: do not assume errno valuesLibravatar Junio C Hamano2-3/+12
A few tests printed 'errno' as an integer and compared with hardcoded integers; this is obviously not portable. A two things to note are: - the string obtained by strerror() is not portable, and cannot be used for the purpose of these tests. - there unfortunately isn't a portable way to map error numbers to error names. As we only care about a few selected errors, just map the error number to the name before emitting for comparison. Reported-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29Merge branch 'jk/xdiff-clamp-funcname-context-index'Libravatar Junio C Hamano1-0/+22
The internal diff machinery can be made to read out of bounds while looking for --funcion-context line in a corner case, which has been corrected. * jk/xdiff-clamp-funcname-context-index: xdiff: clamp function context indices in post-image
2019-07-29Merge branch 'fc/fetch-with-import-fix' into maintLibravatar Junio C Hamano2-13/+27
Code restructuring during 2.20 period broke fetching tags via "import" based transports. * fc/fetch-with-import-fix: fetch: fix regression with transport helpers fetch: make the code more understandable fetch: trivial cleanup t5801 (remote-helpers): add test to fetch tags t5801 (remote-helpers): cleanup refspec stuff
2019-07-29Merge branch 'ds/close-object-store' into maintLibravatar Junio C Hamano1-0/+8
The commit-graph file is now part of the "files that the runtime may keep open file descriptors on, all of which would need to be closed when done with the object store", and the file descriptor to an existing commit-graph file now is closed before "gc" finalizes a new instance to replace it. * ds/close-object-store: packfile: rename close_all_packs to close_object_store packfile: close commit-graph in close_all_packs commit-graph: use raw_object_store when closing commit-graph: extract write_commit_graph_file() commit-graph: extract copy_oids_to_commits() commit-graph: extract count_distinct_commits() commit-graph: extract fill_oids_from_all_packs() commit-graph: extract fill_oids_from_commit_hex() commit-graph: extract fill_oids_from_packs() commit-graph: create write_commit_graph_context commit-graph: remove Future Work section commit-graph: collapse parameters into flags commit-graph: return with errors during write commit-graph: fix the_repository reference
2019-07-29Merge branch 'pw/add-p-recount' into maintLibravatar Junio C Hamano1-0/+8
"git checkout -p" needs to selectively apply a patch in reverse, which did not work well. * pw/add-p-recount: add -p: fix checkout -p with pathological context
2019-07-29Merge branch 'jk/trailers-use-config' into maintLibravatar Junio C Hamano1-27/+44
"git interpret-trailers" always treated '#' as the comment character, regardless of core.commentChar setting, which has been corrected. * jk/trailers-use-config: interpret-trailers: load default config
2019-07-29Merge branch 'tg/stash-ref-by-index-fix' into maintLibravatar Junio C Hamano1-0/+18
"git stash show 23" used to work, but no more after getting rewritten in C; this regression has been corrected. * tg/stash-ref-by-index-fix: stash: fix show referencing stash index
2019-07-29Merge branch 'pw/rebase-abort-clean-rewritten' into maintLibravatar Junio C Hamano1-1/+17
"git rebase --abort" used to leave refs/rewritten/ when concluding "git rebase -r", which has been corrected. * pw/rebase-abort-clean-rewritten: rebase --abort/--quit: cleanup refs/rewritten sequencer: return errors from sequencer_remove_state() rebase: warn if state directory cannot be removed rebase: fix a memory leak
2019-07-29Merge branch 'sg/rebase-progress' into maintLibravatar Junio C Hamano3-75/+55
Use "Erase in Line" CSI sequence that is already used in the editor support to clear cruft in the progress output. * sg/rebase-progress: progress: use term_clear_line() rebase: fix garbled progress display with '-x' pager: add a helper function to clear the last line in the terminal t3404: make the 'rebase.missingCommitsCheck=ignore' test more focused t3404: modernize here doc style