git, branch v2.24.0-rc1

Git 2.24-rc1

2019-10-24T04:34:03Z

Signed-off-by: Junio C Hamano

Merge branch 'sg/ci-osx-gcc8-fix'

2019-10-24T04:34:03Z

CI build fix. * sg/ci-osx-gcc8-fix: ci: fix GCC install in the Travis CI GCC OSX job

Merge branch 'ds/feature-macros'

2019-10-24T04:34:03Z

The codepath that reads the index.version configuration was broken with a recent update, which has been corrected. * ds/feature-macros: repo-settings: read an int for index.version

Merge branch 'js/azure-ci-osx-fix'

2019-10-24T04:34:02Z

Update installation procedure for Perforce on MacOS in the CI jobs running on Azure pipelines, which was failing. * js/azure-ci-osx-fix: ci(osx): use new location of the `perforce` cask

Merge branch 'bw/format-patch-o-create-leading-dirs'

2019-10-24T04:34:02Z

Test update. * bw/format-patch-o-create-leading-dirs: t4014: make output-directory tests self-contained

Merge branch 'dl/submodule-set-branch'

2019-10-24T04:34:02Z

Test update. * dl/submodule-set-branch: t7419: change test_must_fail to ! for grep

repo-settings: read an int for index.version

2019-10-24T02:33:45Z

Several config options were combined into a repo_settings struct in ds/feature-macros, including a move of the "index.version" config setting in 7211b9e (repo-settings: consolidate some config settings, 2019-08-13). Unfortunately, that file looked like a lot of boilerplate and what is clearly a factor of copy-paste overload, the config setting is parsed with repo_config_ge_bool() instead of repo_config_get_int(). This means that a setting "index.version=4" would not register correctly and would revert to the default version of 3. I caught this while incorporating v2.24.0-rc0 into the VFS for Git codebase, where we really care that the index is in version 4. This was not caught by the codebase because the version checks placed in t1600-index.sh did not test the "basic" scenario enough. Here, we modify the test to include these normal settings to not be overridden by features.manyFiles or GIT_INDEX_VERSION. While the "default" version is 3, this is demoted to version 2 in do_write_index() when not necessary. Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

ci: fix GCC install in the Travis CI GCC OSX job

2019-10-24T02:31:07Z

A few days ago Travis CI updated their existing OSX images, including the Homebrew database in the xcode10.1 OSX image that we use. Since then installing dependencies in the 'osx-gcc' job fails when it tries to link gcc@8: + brew link gcc@8 Error: No such keg: /usr/local/Cellar/gcc@8 GCC8 is still installed but not linked to '/usr/local' in the updated image, as it was before this update, but now we have to link it by running 'brew link gcc'. So let's do that then, and fall back to linking gcc@8 if it doesn't, just to be sure. Our builds on Azure Pipelines are unaffected by this issue. The OSX image over there doesn't contain the gcc@8 package, so we have to 'brew install' it, which already takes care of linking it to '/usr/local'. After that the 'brew link gcc' command added by this patch fails, but the ||-chained fallback 'brew link gcc@8' command succeeds with an "already linked" warning. Signed-off-by: SZEDER Gábor Signed-off-by: Junio C Hamano

Eleventh batch

2019-10-23T05:43:11Z

The tenth was at -rc0 ;-) Signed-off-by: Junio C Hamano

Merge branch 'cb/pcre2-chartables-leakfix'

2019-10-23T05:43:11Z

Leakfix. * cb/pcre2-chartables-leakfix: grep: avoid leak of chartables in PCRE2 grep: make PCRE2 aware of custom allocator grep: make PCRE1 aware of custom allocator