git, branch v2.21.0-rc2

Git 2.21-rc2

2019-02-19T21:20:23Z

Signed-off-by: Junio C Hamano

Merge branch 'js/test-tool-gen-nuls'

2019-02-19T21:18:08Z

* js/test-tool-gen-nuls: tests: teach the test-tool to generate NUL bytes and use it

Merge branch 'mk/t5562-no-input-to-too-large-an-input-test'

2019-02-19T21:18:08Z

* 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"

Merge branch 'mk/t5562-do-not-reuse-output-files'

2019-02-19T21:18:08Z

* mk/t5562-do-not-reuse-output-files: t5562: do not reuse output files

t5562: do not reuse output files

2019-02-19T21:04:37Z

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 Helped-by: Carlo Arenas Helped-by: Junio C Hamano Signed-off-by: Max Kirillov Signed-off-by: Junio C Hamano

tests: teach the test-tool to generate NUL bytes and use it

2019-02-19T18:22:21Z

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 Signed-off-by: Junio C Hamano

t5562: do not depend on /dev/zero

2019-02-19T18:19:32Z

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 Signed-off-by: Max Kirillov Signed-off-by: Junio C Hamano

Revert "t5562: replace /dev/zero with a pipe from generate_zero_bytes"

2019-02-19T18:19:22Z

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.

mingw: safe-guard a bit more against getenv() problems

2019-02-15T18:25:28Z

Running up to v2.21.0, we fixed two bugs that were made prominent by the Windows-specific change to retain copies of only the 30 latest getenv() calls' returned strings, invalidating any copies of previous getenv() calls' return values. While this really shines a light onto bugs of the form where we hold onto getenv()'s return values without copying them, it is also a real problem for users. And even if Jeff King's patches merged via 773e408881 (Merge branch 'jk/save-getenv-result', 2019-01-29) provide further work on that front, we are far from done. Just one example: on Windows, we unset environment variables when spawning new processes, which potentially invalidates strings that were previously obtained via getenv(), and therefore we have to duplicate environment values that are somehow involved in spawning new processes (e.g. GIT_MAN_VIEWER in show_man_page()). We do not have a chance to investigate, let address, all of those issues in time for v2.21.0, so let's at least help Windows users by increasing the number of getenv() calls' return values that are kept valid. The number 64 was determined by looking at the average number of getenv() calls per process in the entire test suite run on Windows (which is around 40) and then adding a bit for good measure. And it is a power of two (which would have hit yesterday's theme perfectly). Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'ea/rebase-compat-doc-fix'

2019-02-14T22:28:22Z

* ea/rebase-compat-doc-fix: docs/git-rebase: remove redundant entry in incompatible options list