summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2019-03-04tests: introduce --stress-jobs=<N>Libravatar Johannes Schindelin2-3/+11
The --stress option currently accepts an argument, but it is confusing to at least this user that the argument does not define the maximal number of stress iterations, but instead the number of jobs to run in parallel per stress iteration. Let's introduce a separate option for that, whose name makes it more obvious what it is about, and let --stress=<N> error out with a helpful suggestion about the two options tha could possibly have been meant. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-04tests: let --stress-limit=<N> imply --stressLibravatar Johannes Schindelin2-1/+2
It does not make much sense that running a test with --stress-limit=<N> seemingly ignores that option because it does not stress test at all. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-22Merge branch 'ab/bsd-fixes'Libravatar Junio C Hamano2-5/+5
Test portability fix. * ab/bsd-fixes: commit-graph tests: fix unportable "dd" invocation tests: fix unportable "\?" and "\+" regex syntax
2019-02-22Merge branch 'ab/workaround-dash-bug-in-test'Libravatar Junio C Hamano1-0/+1
* ab/workaround-dash-bug-in-test: tests: avoid syntax triggering old dash bug
2019-02-22commit-graph tests: fix unportable "dd" invocationLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Change an unportable invocation of "dd" with count=0, that wanted to truncate the commit-graph file. In POSIX it is unspecified what happens when count=0 is provided[1]. The NetBSD "dd" behavior differs from GNU (and seemingly other BSDs), which has left this test broken since d2b86fbaa1 ("commit-graph: fix buffer read-overflow", 2019-01-15). Copying from /dev/null would seek/truncate to seek=$zero_pos and stop immediately after that (without being able to copy anything), which is the right way to truncate the file. 1. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/dd.html Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-21tests: fix unportable "\?" and "\+" regex syntaxLibravatar Ævar Arnfjörð Bjarmason1-4/+4
Fix widely supported but non-POSIX basic regex syntax introduced in [1] and [2]. On GNU, NetBSD and FreeBSD the following works: $ echo xy >f $ grep 'xy\?' f; echo $? xy 0 The same goes for "\+". The "?" and "+" syntax is not in the BRE syntax, just in ERE, but on some implementations it can be invoked by prefixing the meta-operator with "\", but not on OpenBSD: $ uname -a OpenBSD obsd.my.domain 6.2 GENERIC#132 amd64 $ grep --version grep version 0.9 $ grep 'xy\?' f; echo $? 1 Let's fix this by moving to ERE syntax instead, where "?" and "+" are universally supported: $ grep -E 'xy?' f; echo $? xy 0 1. 2ed5c8e174 ("describe: setup working tree for --dirty", 2019-02-03) 2. c801170b0c ("t6120: test for describe with a bare repository", 2019-02-03) Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-19Merge branch 'js/test-tool-gen-nuls'Libravatar Junio C Hamano4-7/+24
* js/test-tool-gen-nuls: tests: teach the test-tool to generate NUL bytes and use it
2019-02-19Merge branch 'mk/t5562-no-input-to-too-large-an-input-test'Libravatar Junio C Hamano1-2/+2
* mk/t5562-no-input-to-too-large-an-input-test: t5562: do not depend on /dev/zero Revert "t5562: replace /dev/zero with a pipe from generate_zero_bytes"
2019-02-19t5562: do not reuse output filesLibravatar Max Kirillov1-4/+4
Some expected failures of git-http-backend leaves running its children (receive-pack or upload-pack) which still hold opened descriptors to act.err and with some probability they live long enough to write there their failure messages after next test has already truncated the files. This causes occasional failures of the test script. Avoid the issue by using separated output and error file for each test, apprending the test number to their name. Reported-by: Carlo Arenas <carenas@gmail.com> Helped-by: Carlo Arenas <carenas@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Max Kirillov <max@max630.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-19tests: teach the test-tool to generate NUL bytes and use itLibravatar Johannes Schindelin4-7/+24
In cc95bc2025 (t5562: replace /dev/zero with a pipe from generate_zero_bytes, 2019-02-09), we replaced usage of /dev/zero (which is not available on NonStop, apparently) by a Perl script snippet to generate NUL bytes. Sadly, it does not seem to work on NonStop, as t5562 reportedly hangs. Worse, this also hangs in the Ubuntu 16.04 agents of the CI builds on Azure Pipelines: for some reason, the Perl script snippet that is run via `generate_zero_bytes` in t5562's 'CONTENT_LENGTH overflow ssite_t' test case tries to write out an infinite amount of NUL bytes unless a broken pipe is encountered, that snippet never encounters the broken pipe, and keeps going until the build times out. Oddly enough, this does not reproduce on the Windows and macOS agents, nor in a local Ubuntu 18.04. This developer tried for a day to figure out the exact circumstances under which this hang happens, to no avail, the details remain a mystery. In the end, though, what counts is that this here change incidentally fixes that hang (maybe also on NonStop?). Even more positively, it gets rid of yet another unnecessary Perl invocation. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-19t5562: do not depend on /dev/zeroLibravatar Max Kirillov1-1/+1
It was reported [1] that NonStop platform does not have /dev/zero. The test uses /dev/zero as a dummy input. Passing case (http-backed failed because of too big input size) should not be reading anything from it. If http-backend would erroneously try to read any data returning EOF probably would be even safer than providing some meaningless data. Replace /dev/zero with /dev/null to avoid issues with platforms which do not have /dev/zero. [1] https://public-inbox.org/git/20190209185930.5256-4-randall.s.becker@rogers.com/ Reported-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Max Kirillov <max@max630.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-19Revert "t5562: replace /dev/zero with a pipe from generate_zero_bytes"Libravatar Junio C Hamano1-2/+2
Revert cc95bc20 ("t5562: replace /dev/zero with a pipe from generate_zero_bytes", 2019-02-09), as not feeding anything to the command is a better way to test it.
2019-02-14Merge branch 'jc/no-grepping-for-strerror-in-tests'Libravatar Junio C Hamano1-1/+1
* jc/no-grepping-for-strerror-in-tests: t1404: do not rely on the exact phrasing of strerror()
2019-02-14Merge branch 'jt/fetch-v2-sideband'Libravatar Junio C Hamano1-0/+1
"git fetch" and "git upload-pack" learned to send all exchange over the sideband channel while talking the v2 protocol. * jt/fetch-v2-sideband: t/lib-httpd: pass GIT_TEST_SIDEBAND_ALL through Apache
2019-02-14t/lib-httpd: pass GIT_TEST_SIDEBAND_ALL through ApacheLibravatar Todd Zullinger1-0/+1
07c3c2aa16 ("tests: define GIT_TEST_SIDEBAND_ALL", 2019-01-16) added GIT_TEST_SIDEBAND_ALL to the apache.conf PassEnv list. Avoid warnings from Apache when the variable is unset, as we do for GIT_VALGRIND* and GIT_TRACE, from f628825481 ("t/lib-httpd: handle running under --valgrind", 2012-07-24) and 89c57ab3f0 ("t: pass GIT_TRACE through Apache", 2015-03-13), respectively. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-14t1404: do not rely on the exact phrasing of strerror()Libravatar Junio C Hamano1-1/+1
Not even in C locale, it is wrong to expect that the exact phrasing "File exists" is used to show EEXIST. Reported-by: Randall S. Becker <rsbecker@nexbridge.com> Helped-by: Duy Nguyen <pclouds@gmail.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-13Merge branch 'ab/rebase-test-fix'Libravatar Junio C Hamano1-3/+6
* ab/rebase-test-fix: rebase: fix regression in rebase.useBuiltin=false test mode
2019-02-13Merge branch 'rb/no-dev-zero-in-test'Libravatar Junio C Hamano3-3/+16
* rb/no-dev-zero-in-test: t5562: replace /dev/zero with a pipe from generate_zero_bytes t5318: replace use of /dev/zero with generate_zero_bytes test-lib-functions.sh: add generate_zero_bytes function
2019-02-13Merge branch 'sg/stress-test'Libravatar Junio C Hamano3-4/+23
Test improvement. * sg/stress-test: test-lib: fix non-portable pattern bracket expressions test-lib: make '--stress' more bisect-friendly
2019-02-13Merge branch 'kd/t0028-octal-del-is-377-not-777'Libravatar Junio C Hamano1-4/+4
Test fix. * kd/t0028-octal-del-is-377-not-777: t0028: fix wrong octal values for BOM in setup
2019-02-13rebase: fix regression in rebase.useBuiltin=false test modeLibravatar Ævar Arnfjörð Bjarmason1-3/+6
Fix a recently introduced regression in c762aada1a ("rebase -x: sanity check command", 2019-01-29) triggered when running the tests with GIT_TEST_REBASE_USE_BUILTIN=false. See 62c23938fa ("tests: add a special setup where rebase.useBuiltin is off", 2018-11-14) for how that test mode works. As discussed on-list[1] it's not worth it to implement the sanity check in the legacy rebase code, we plan to remove it after the 2.21 release. So let's do the bare minimum to make the tests pass under the GIT_TEST_REBASE_USE_BUILTIN=false special setup. 1. https://public-inbox.org/git/xmqqva1nbeno.fsf@gitster-ct.c.googlers.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-13tests: avoid syntax triggering old dash bugLibravatar Ævar Arnfjörð Bjarmason1-0/+1
Avoid a bug in dash that's been fixed ever since its ec2c84d ("[PARSER] Fix clobbering of checkkwd", 2011-03-15)[1] first released with dash v0.5.7 in July 2011. This failing test was introduced in 5f9674243d ("config: add --expiry-date", 2017-11-18). This fixes 1/2 tests failing on Debian Lenny & Squeeze. The other failure is due to 1b42f45255 ("git-svn: apply "svn.pathnameencoding" before URL encoding", 2016-02-09). The dash bug is triggered by this test because the heredoc contains a command embedded in "$()" with a "{}" block coming right after it. Refactoring the "$()" to e.g. be a variable that was set earlier will also work around it, but let's instead break up the "EOF" and the "{}". An earlier version of this patch[2] mitigated the issue by breaking the "$()" out of the "{}" block, that worked, but just because it broke up the "EOF" and "{}" block. Putting e.g. "echo &&" between the two would also work. 1. https://git.kernel.org/pub/scm/utils/dash/dash.git/ 2. https://public-inbox.org/git/20181127164253.9832-1-avarab@gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-13t5562: replace /dev/zero with a pipe from generate_zero_bytesLibravatar Randall S. Becker1-2/+2
To help platforms that lack /dev/zero (e.g. NonStop), replace use of /dev/zero to feed "git http-backend" with a pipe of output from the generate_zero_bytes helper. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-13t5318: replace use of /dev/zero with generate_zero_bytesLibravatar Randall S. Becker1-1/+1
There are platforms (e.g. NonStop) that lack /dev/zero; use the generate_zero_bytes helper we just introduced to append stream of NULs at the end of the file. The original, even though it uses "dd seek=... count=..." to make it look like it is overwriting the middle part of an existing file, has truncated the file before this step with another use of "dd", which may make it tricky to see why this rewrite is a correct one. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-12test-lib-functions.sh: add generate_zero_bytes functionLibravatar Randall S. Becker1-0/+13
t5318 and t5562 used /dev/zero, which is not portable. This function provides both a fixed block of NUL bytes and an infinite stream of NULs. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-11utf8: handle systems that don't write BOM for UTF-16Libravatar brian m. carlson1-5/+29
When serializing UTF-16 (and UTF-32), there are three possible ways to write the stream. One can write the data with a BOM in either big-endian or little-endian format, or one can write the data without a BOM in big-endian format. Most systems' iconv implementations choose to write it with a BOM in some endianness, since this is the most foolproof, and it is resistant to misinterpretation on Windows, where UTF-16 and the little-endian serialization are very common. For compatibility with Windows and to avoid accidental misuse there, Git always wants to write UTF-16 with a BOM, and will refuse to read UTF-16 without it. However, musl's iconv implementation writes UTF-16 without a BOM, relying on the user to interpret it as big-endian. This causes t0028 and the related functionality to fail, since Git won't read the file without a BOM. Add a Makefile and #define knob, ICONV_OMITS_BOM, that can be set if the iconv implementation has this behavior. When set, Git will write a BOM manually for UTF-16 and UTF-32 and then force the data to be written in UTF-16BE or UTF-32BE. We choose big-endian behavior here because the tests use the raw "UTF-16" encoding, which will be big-endian when the implementation requires this knob to be set. Update the tests to detect this case and write test data with an added BOM if necessary. Always write the BOM in the tests in big-endian format, since all iconv implementations that omit a BOM must use big-endian serialization according to the Unicode standard. Preserve the existing behavior for systems which do not have this knob enabled, since they may use optimized implementations, including defaulting to the native endianness, which may improve performance. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-11t0028: fix wrong octal values for BOM in setupLibravatar Kevin Daudt1-4/+4
The setup code uses octal values with printf to generate a BOM for UTF-16/32 BE/LE. It specifically uses '\777' to emit a 0xff byte. This relies on the fact that most shells truncate the value above 0o377. Ash however interprets '\777' as '\77' + a literal '7', resulting in an invalid BOM. Fix this by using the proper value of 0xff: '\377'. Signed-off-by: Kevin Daudt <me@ikke.info> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-11test-lib: fix non-portable pattern bracket expressionsLibravatar SZEDER Gábor2-3/+3
Use a '!' character to start a non-matching pattern bracket expression, as specified by POSIX in Shell Command Language section 2.13.1 Patterns Matching a Single Character [1]. I used '^' instead in three places in the previous three commits, to verify that the arguments of the '--stress=' and '--stress-limit=' options and the values of various '*_PORT' environment variables are valid numbers. With certain shells, at least with dash (upstream and in Ubuntu 14.04) and mksh, this led to various undesired behaviors: # error message in case of a valid number $ ~/src/dash/src/dash ./t3903-stash.sh --stress=8 error: --stress=<N> requires the number of jobs to run # not the expected error message $ ~/src/dash/src/dash ./t3903-stash.sh --stress=foo ./t3903-stash.sh: 238: test: Illegal number: foo # no error message at all?! $ mksh ./t3903-stash.sh --stress=foo $ echo $? 0 Some other shells, e.g. Bash (even in posix mode), ksh, dash in Ubuntu 16.04 or later, are apparently happy to accept '^' just as well. [1] http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13 Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-08Merge branch 'ld/git-p4-remove-flakey-test'Libravatar Junio C Hamano1-27/+0
A flakey "p4" test has been removed. * ld/git-p4-remove-flakey-test: git-p4: remove ticket expiry test
2019-02-08Merge branch 'js/rebase-i-redo-exec-fix'Libravatar Junio C Hamano1-3/+0
For "rebase -i --reschedule-failed-exec", we do not want the "-y" shortcut after all. * js/rebase-i-redo-exec-fix: Revert "rebase: introduce a shortcut for --reschedule-failed-exec"
2019-02-08Merge branch 'js/smart-http-detect-remote-error'Libravatar Junio C Hamano4-0/+13
Some errors from the other side coming over smart HTTP transport were not noticed, which has been corrected. * js/smart-http-detect-remote-error: t5551: test server-side ERR packet remote-curl: tighten "version 2" check for smart-http remote-curl: refactor smart-http discovery
2019-02-08Merge branch 'tz/gpg-test-fix'Libravatar Junio C Hamano1-2/+1
Test fix. * tz/gpg-test-fix: t/lib-gpg: drop redundant killing of gpg-agent t/lib-gpg: quote path to ${GNUPGHOME}/trustlist.txt
2019-02-08Merge branch 'os/rebase-runs-post-checkout-hook'Libravatar Junio C Hamano1-1/+1
Test fix. * os/rebase-runs-post-checkout-hook: t5403: correct bash ambiguous redirect error in subtest 8 by quoting $GIT_DIR
2019-02-08test-lib: make '--stress' more bisect-friendlyLibravatar SZEDER Gábor2-2/+21
Let's suppose that a test somehow becomes flaky between 'master' and 'pu', and tends to fail within the first 50 repetitions when run with '--stress'. In such a case we could use 'git bisect' to find the culprit: if the test script fails with '--stress', then the commit is definitely bad, but if it survives, say, 300 repetitions, then we could consider it good with reasonable confidence. Unfortunately, all this could only be done manually, because '--stress' would run the test script repeatedly for all eternity on a good commit, and it would exit with success even when it found a failure on a bad commit. So let's make '--stress' usable with 'git bisect run': - Make it exit with failure if a failure is found. - Add the '--stress-limit=<N>' option to repeat the test script at most N times in each of the parallel jobs, and exit with success when the limit is reached. And then we could simply run something like: $ git bisect start origin/pu master $ git bisect run sh -c 'make && cd t && ./t1234-foo.sh --stress --stress-limit=300' Sure, as a brand new feature it won't be any useful right now, but in a release or three most cooking topics will already contain this, so we could automatically bisect at least newly introduced flakiness. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-08t5403: correct bash ambiguous redirect error in subtest 8 by quoting $GIT_DIRLibravatar Randall S. Becker1-1/+1
The embedded blanks in the full path of the test git repository cased bash to generate an ambugious redirect error. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-08t/lib-gpg: drop redundant killing of gpg-agentLibravatar Todd Zullinger1-1/+0
In 53fc999306 ("gpg-interface t: extend the existing GPG tests with GPGSM", 2018-07-20), the gpgconf call which kills gpg-agent was copied from the existing gpg setup code. The reason for killing gpg-agent is given in 29ff1f8f74 ("t: lib-gpg: flush gpg agent on startup", 2017-07-20): When running gpg-relevant tests, a gpg-daemon is spawned for each GNUPGHOME used. This daemon may stay running after the test and cache file descriptors for the trash directories, even after the trash directory is removed. This leads to ENOENT errors when attempting to create files if tests are run multiple times. Add a cleanup script to force flushing the gpg-agent for that GNUPGHOME (if any) before setting up the GPG relevant-environment. Killing gpg-agent once per test is sufficient. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-08t/lib-gpg: quote path to ${GNUPGHOME}/trustlist.txtLibravatar Todd Zullinger1-1/+1
When gpgsm is installed, lib-gpg.sh attempts to update trustlist.txt to relax the checking of some root certificate requirements. The path to "${GNUPGHOME}" contains spaces which cause an "ambiguous redirect" warning when bash is used to run the tests: $ bash t7030-verify-tag.sh /git/t/lib-gpg.sh: line 66: ${GNUPGHOME}/trustlist.txt: ambiguous redirect ok 1 - create signed tags ok 2 # skip create signed tags x509 (missing GPGSM) ... No warning is issued when using bash called as /bin/sh, dash, or mksh. Quote the path to ensure the redirect works as intended and sets the GPGSM prereq. While we're here, drop the space after ">>". Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-02-06Merge branch 'ss/describe-dirty-in-the-right-directory'Libravatar Junio C Hamano1-0/+39
"git --work-tree=$there --git-dir=$here describe --dirty" did not work correctly as it did not pay attention to the location of the worktree specified by the user by mistake, which has been corrected. * ss/describe-dirty-in-the-right-directory: t6120: test for describe with a bare repository describe: setup working tree for --dirty
2019-02-06Merge branch 'jk/loose-object-cache-oid'Libravatar Junio C Hamano1-1/+1
Code clean-up. * jk/loose-object-cache-oid: prefer "hash mismatch" to "sha1 mismatch" sha1-file: avoid "sha1 file" for generic use in messages sha1-file: prefer "loose object file" to "sha1 file" in messages sha1-file: drop has_sha1_file() convert has_sha1_file() callers to has_object_file() sha1-file: convert pass-through functions to object_id sha1-file: modernize loose header/stream functions sha1-file: modernize loose object file functions http: use struct object_id instead of bare sha1 update comment references to sha1_object_info() sha1-file: fix outdated sha1 comment references
2019-02-06Merge branch 'pw/rebase-x-sanity-check'Libravatar Junio C Hamano1-0/+19
"git rebase -x $cmd" did not reject multi-line command, even though the command is incapable of handling such a command. It now is rejected upfront. * pw/rebase-x-sanity-check: rebase -x: sanity check command
2019-02-06Merge branch 'js/vsts-ci'Libravatar Junio C Hamano13-13/+304
Prepare to run test suite on Azure Pipeline. * js/vsts-ci: (22 commits) test-date: drop unused parameter to getnanos() ci: parallelize testing on Windows ci: speed up Windows phase tests: optionally skip bin-wrappers/ t0061: workaround issues with --with-dashes and RUNTIME_PREFIX tests: add t/helper/ to the PATH with --with-dashes mingw: try to work around issues with the test cleanup tests: include detailed trace logs with --write-junit-xml upon failure tests: avoid calling Perl just to determine file sizes README: add a build badge (status of the Azure Pipelines build) mingw: be more generous when wrapping up the setitimer() emulation ci: use git-sdk-64-minimal build artifact ci: add a Windows job to the Azure Pipelines definition Add a build definition for Azure DevOps ci/lib.sh: add support for Azure Pipelines tests: optionally write results as JUnit-style .xml test-date: add a subcommand to measure times in shell scripts ci: use a junction on Windows instead of a symlink ci: inherit --jobs via MAKEFLAGS in run-build-and-tests ci/lib.sh: encapsulate Travis-specific things ...
2019-02-06Merge branch 'br/commit-tree-fully-spelled-gpg-sign-option'Libravatar Junio C Hamano1-4/+17
The documentation of "git commit-tree" said that the command understands "--gpg-sign" in addition to "-S", but the command line parser did not know about the longhand, which has been corrected. * br/commit-tree-fully-spelled-gpg-sign-option: commit-tree: add missing --gpg-sign flag t7510: invoke git as part of &&-chain
2019-02-06Merge branch 'ds/push-sparse-tree-walk'Libravatar Junio C Hamano2-0/+140
"git pack-objects" learned another algorithm to compute the set of objects to send, that trades the resulting packfile off to save traversal cost to favor small pushes. * ds/push-sparse-tree-walk: pack-objects: create GIT_TEST_PACK_SPARSE pack-objects: create pack.useSparse setting revision: implement sparse algorithm list-objects: consume sparse tree walk revision: add mark_tree_uninteresting_sparse
2019-02-06Merge branch 'tb/test-lint-sed-options'Libravatar Junio C Hamano1-1/+1
The test lint learned to catch non-portable "sed" options. * tb/test-lint-sed-options: test-lint: only use only sed [-n] [-e command] [-f command_file]
2019-02-06Merge branch 'lt/date-human'Libravatar Junio C Hamano2-3/+32
A new date format "--date=human" that morphs its output depending on how far the time is from the current time has been introduced. "--date=auto" can be used to use this new format when the output is going to the pager or to the terminal and otherwise the default format. * lt/date-human: Add `human` date format tests. Add `human` format to test-tool Add 'human' date format documentation Replace the proposed 'auto' mode with 'auto:' Add 'human' date format
2019-02-06Merge branch 'jk/unused-parameter-cleanup'Libravatar Junio C Hamano1-1/+1
Code cleanup. * jk/unused-parameter-cleanup: convert: drop path parameter from actual conversion functions convert: drop len parameter from conversion checks config: drop unused parameter from maybe_remove_section() show_date_relative(): drop unused "tz" parameter column: drop unused "opts" parameter in item_length() create_bundle(): drop unused "header" parameter apply: drop unused "def" parameter from find_name_gnu() match-trees: drop unused path parameter from score functions
2019-02-06Merge branch 'nd/the-index-final'Libravatar Junio C Hamano3-2/+4
The assumption to work on the single "in-core index" instance has been reduced from the library-ish part of the codebase. * nd/the-index-final: cache.h: flip NO_THE_INDEX_COMPATIBILITY_MACROS switch read-cache.c: remove the_* from index_has_changes() merge-recursive.c: remove implicit dependency on the_repository merge-recursive.c: remove implicit dependency on the_index sha1-name.c: remove implicit dependency on the_index read-cache.c: replace update_index_if_able with repo_& read-cache.c: kill read_index() checkout: avoid the_index when possible repository.c: replace hold_locked_index() with repo_hold_locked_index() notes-utils.c: remove the_repository references grep: use grep_opt->repo instead of explict repo argument
2019-02-06Merge branch 'tt/bisect-in-c'Libravatar Junio C Hamano1-1/+1
More code in "git bisect" has been rewritten in C. * tt/bisect-in-c: bisect--helper: `bisect_start` shell function partially in C bisect--helper: `get_terms` & `bisect_terms` shell function in C bisect--helper: `bisect_next_check` shell function in C bisect--helper: `check_and_set_terms` shell function in C wrapper: move is_empty_file() and rename it as is_empty_or_missing_file() bisect--helper: `bisect_write` shell function in C bisect--helper: `bisect_reset` shell function in C
2019-02-06Merge branch 'tb/utf-16-le-with-explicit-bom'Libravatar Junio C Hamano1-1/+11
A new encoding UTF-16LE-BOM has been invented to force encoding to UTF-16 with BOM in little endian byte order, which cannot be directly generated by using iconv. * tb/utf-16-le-with-explicit-bom: Support working-tree-encoding "UTF-16LE-BOM"
2019-02-06Merge branch 'dt/cat-file-batch-ambiguous'Libravatar Junio C Hamano1-0/+10
"git cat-file --batch" reported a dangling symbolic link by mistake, when it wanted to report that a given name is ambiguous. * dt/cat-file-batch-ambiguous: t1512: test ambiguous cat-file --batch and --batch-output Do not print 'dangling' for cat-file in case of ambiguity