summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-10-29l10n: bg.po: Updated Bulgarian translation (4694)Libravatar Alexander Shopov1-87/+51
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2019-10-29Merge branch 'l10n/it/update-italian-translation'Libravatar Jiang Xin1-61/+67
* 'update-italian-translation' of github.com:AlessandroMenti/git-po: l10n: it.po: update the Italian translation for Git 2.24.0 round #2
2019-10-28l10n: it.po: update the Italian translation for Git 2.24.0 round #2Libravatar Alessandro Menti1-61/+67
Signed-off-by: Alessandro Menti <alessandro.menti@alessandromenti.it>
2019-10-28l10n: fr v2.24.0 rnd2Libravatar Jean-Noël Avila1-55/+75
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
2019-10-28l10n: git.pot: v2.24.0 round 2 (1 new)Libravatar Jiang Xin1-45/+50
Generate po/git.pot from v2.24.0-rc1 for git v2.24.0 l10n round 2. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2019-10-28Merge tag 'v2.24.0-rc1' of github.com:git/git into masterLibravatar Jiang Xin27-29/+247
Git 2.24-rc1 * tag 'v2.24.0-rc1' of github.com:git/git: Git 2.24-rc1 repo-settings: read an int for index.version ci: fix GCC install in the Travis CI GCC OSX job Eleventh batch ci(osx): use new location of the `perforce` cask t7419: change test_must_fail to ! for grep t4014: make output-directory tests self-contained ci(visual-studio): actually run the tests in parallel ci(visual-studio): use strict compile flags, and optimization userdiff: fix some corner cases in dts regex test-progress: fix test failures on big-endian systems completion: clarify installation instruction for zsh grep: avoid leak of chartables in PCRE2 grep: make PCRE2 aware of custom allocator grep: make PCRE1 aware of custom allocator remote-curl: pass on atomic capability to remote side diff-highlight: fix a whitespace nit fsmonitor: don't fill bitmap with entries to be removed
2019-10-24Git 2.24-rc1Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-24Merge branch 'sg/ci-osx-gcc8-fix'Libravatar Junio C Hamano1-0/+1
CI build fix. * sg/ci-osx-gcc8-fix: ci: fix GCC install in the Travis CI GCC OSX job
2019-10-24Merge branch 'ds/feature-macros'Libravatar Junio C Hamano2-1/+5
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
2019-10-24Merge branch 'js/azure-ci-osx-fix'Libravatar Junio C Hamano1-0/+5
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
2019-10-24Merge branch 'bw/format-patch-o-create-leading-dirs'Libravatar Junio C Hamano1-5/+8
Test update. * bw/format-patch-o-create-leading-dirs: t4014: make output-directory tests self-contained
2019-10-24Merge branch 'dl/submodule-set-branch'Libravatar Junio C Hamano1-3/+3
Test update. * dl/submodule-set-branch: t7419: change test_must_fail to ! for grep
2019-10-24repo-settings: read an int for index.versionLibravatar Derrick Stolee2-1/+5
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 <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-24ci: fix GCC install in the Travis CI GCC OSX jobLibravatar SZEDER Gábor1-0/+1
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 <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23Eleventh batchLibravatar Junio C Hamano1-0/+10
The tenth was at -rc0 ;-) Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23Merge branch 'cb/pcre2-chartables-leakfix'Libravatar Junio C Hamano3-3/+47
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
2019-10-23Merge branch 'bc/smart-http-atomic-push'Libravatar Junio C Hamano5-3/+62
The atomic push over smart HTTP transport did not work, which has been corrected. * bc/smart-http-atomic-push: remote-curl: pass on atomic capability to remote side
2019-10-23Merge branch 'wb/fsmonitor-bitmap-fix'Libravatar Junio C Hamano3-5/+65
A segfault fix. * wb/fsmonitor-bitmap-fix: fsmonitor: don't fill bitmap with entries to be removed
2019-10-23Merge branch 'sb/userdiff-dts'Libravatar Junio C Hamano5-2/+33
Tweak userdiff patterns for dts. * sb/userdiff-dts: userdiff: fix some corner cases in dts regex
2019-10-23Merge branch 'sg/progress-fix'Libravatar Junio C Hamano1-1/+1
Byte-order fix the recent update to progress display code. * sg/progress-fix: test-progress: fix test failures on big-endian systems
2019-10-23Merge branch 'nr/diff-highlight-indent-fix'Libravatar Junio C Hamano1-1/+1
Code cleanup. * nr/diff-highlight-indent-fix: diff-highlight: fix a whitespace nit
2019-10-23Merge branch 'mb/clarify-zsh-completion-doc'Libravatar Junio C Hamano1-2/+3
The installation instruction for zsh completion script (in contrib/) has been a bit improved. * mb/clarify-zsh-completion-doc: completion: clarify installation instruction for zsh
2019-10-23ci(osx): use new location of the `perforce` caskLibravatar Johannes Schindelin1-0/+5
The Azure Pipelines builds are failing for macOS due to a change in the location of the perforce cask. The command outputs the following error: + brew install caskroom/cask/perforce Error: caskroom/cask was moved. Tap homebrew/cask-cask instead. So let's try to call `brew cask install perforce` first (which is what that error message suggests, in a most round-about way). Prior to 672f51cb we used to install the 'perforce' package with 'brew install perforce' (note: no 'cask' in there). The justification for 672f51cb was that the command 'brew install perforce' simply stopped working, after Homebrew folks decided that it's better to move the 'perforce' package to a "cask". Their justification for this move was that 'brew install perforce' "can fail due to a checksum mismatch ...", and casks can be installed without checksum verification. And indeed, both 'brew cask install perforce' and 'brew install caskroom/cask/perforce' printed something along the lines of: ==> No checksum defined for Cask perforce, skipping verification It is unclear why 672f51cb used 'brew install caskroom/cask/perforce' instead of 'brew cask install perforce'. It appears (by running both commands on old Travis CI macOS images) that both commands worked all the same already back then. In any case, as the error message at the top of this commit message shows, 'brew install caskroom/cask/perforce' has stopped working recently, but 'brew cask install perforce' still does, so let's use that. CI servers are typically fresh virtual machines, but not always. To accommodate for that, let's try harder if `brew cask install perforce` fails, by specifically pulling the latest `master` of the `homebrew-cask` repository. This will still fail, of course, when `homebrew-cask` falls behind Perforce's release schedule. But once it is updated, we can now simply re-run the failed jobs and they will pick up that update. As for updating `homebrew-cask`: the beginnings of automating this in https://dev.azure.com/gitgitgadget/git/_build?definitionId=11&_a=summary will be finished once the next Perforce upgrade comes around. Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23t7419: change test_must_fail to ! for grepLibravatar Denton Liu1-3/+3
According to t/README, test_must_fail() should only be used to test for failure in Git commands. Replace the invocations of `test_must_fail grep` with `! grep`. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23t4014: make output-directory tests self-containedLibravatar Bert Wesarg1-5/+8
As noted by Gábor in [1], the new tests in edefc31873 ("format-patch: create leading components of output directory", 2019-10-11) cannot be run independently. Fix this. [1] https://public-inbox.org/git/20191011144650.GM29845@szeder.dev/ Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23Merge branch 'js/azure-pipelines-msvc'Libravatar Junio C Hamano1-2/+2
* js/azure-pipelines-msvc: ci(visual-studio): actually run the tests in parallel ci(visual-studio): use strict compile flags, and optimization
2019-10-23ci(visual-studio): actually run the tests in parallelLibravatar Johannes Schindelin1-1/+1
Originally, the CI/PR builds that build and test using Visual Studio were implemented imitating `linux-clang`, i.e. still using the `Makefile`-based build infrastructure. Later (but still before the patches made their way into git.git's `master`), however, this was changed to generate Visual Studio project files and build the binaries using `MSBuild`, as this reflects more accurately how Visual Studio users would want to build Git (internally, Visual Studio uses `MSBuild`, or at least something very similar). During that transition, we needed to implement a new way to run the test suite in parallel, as Visual Studio users typically will only have a Git Bash available (which does not ship with `make` nor with support for `prove`): we simply implemented a new test helper to run the test suite. This helper even knows how to run the tests in parallel, but due to a mistake on this developer's part, it was never turned on in the CI/PR builds. This results in 2x-3x longer run times of the test phase. Let's use the `--jobs=10` option to fix this. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23ci(visual-studio): use strict compile flags, and optimizationLibravatar Johannes Schindelin1-1/+1
To make full use of the work that went into the Visual Studio build & test jobs in our CI/PR builds, let's turn on strict compiler flags. This will give us the benefit of Visual C's compiler warnings (which, at times, seem to catch things that GCC does not catch, and vice versa). While at it, also turn on optimization; It does not make sense to produce binaries with debug information, and we can use any ounce of speed that we get (because the test suite is particularly slow on Windows, thanks to the need to run inside a Unix shell, which requires us to use the POSIX emulation layer provided by MSYS2). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-22l10n: it.po: update the Italian translation for Git 2.24.0Libravatar Alessandro Menti1-2427/+2565
Signed-off-by: Alessandro Menti <alessandro.menti@alessandromenti.it>
2019-10-22Merge branch 'master' of github.com:jnavila/git into git-po-masterLibravatar Jiang Xin1-2430/+2510
* 'master' of github.com:jnavila/git: l10n: fr 2.24.0 rnd 1
2019-10-22Merge branch 'master' of github.com:alshopov/git-po into git-po-masterLibravatar Jiang Xin1-2425/+2560
* 'master' of github.com:alshopov/git-po: l10n: bg.po: Updated Bulgarian translation (4693)
2019-10-21l10n: fr 2.24.0 rnd 1Libravatar Jean-Noël Avila1-2430/+2510
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
2019-10-21Merge remote-tracking branch 'git-po/master' into git-po-masterLibravatar Jiang Xin2-527/+539
* git-po/master: l10n: sv.po: Update Swedish translation (4674t0f0u) l10n: Update Catalan translation
2019-10-21l10n: git.pot: v2.24.0 round 1 (35 new, 16 removed)Libravatar Jiang Xin1-2397/+2484
Generate po/git.pot from v2.24.0-rc0 for git v2.24.0 l10n round 1. Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com>
2019-10-21userdiff: fix some corner cases in dts regexLibravatar Stephen Boyd5-2/+33
While reviewing some dts diffs recently I noticed that the hunk header logic was failing to find the containing node. This is because the regex doesn't consider properties that may span multiple lines, i.e. property = <something>, <something_else>; and it got hung up on comments inside nodes that look like the root node because they start with '/*'. Add tests for these cases and update the regex to find them. Maybe detecting the root node is too complicated but forcing it to be a backslash with any amount of whitespace up to an open bracket seemed OK. I tried to detect that a comment is in-between the two parts but I wasn't happy so I just dropped it. Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-21test-progress: fix test failures on big-endian systemsLibravatar SZEDER Gábor1-1/+1
In 't0500-progress-display.sh' all tests running 'test-tool progress --total=<N>' fail on big-endian systems, e.g. like this: + test-tool progress --total=3 Working hard [...] + test_i18ncmp expect out --- expect 2019-10-18 23:07:54.765523916 +0000 +++ out 2019-10-18 23:07:54.773523916 +0000 @@ -1,4 +1,2 @@ -Working hard: 33% (1/3)<CR> -Working hard: 66% (2/3)<CR> -Working hard: 100% (3/3)<CR> -Working hard: 100% (3/3), done. +Working hard: 0% (1/12884901888)<CR> +Working hard: 0% (3/12884901888), done. The reason for that bogus value is that '--total's parameter is parsed via parse-options's OPT_INTEGER into a uint64_t variable [1], so the two bits of 3 end up in the "wrong" bytes on big-endian systems (12884901888 = 0x300000000). Change the type of that variable from uint64_t to int, to match what parse-options expects; in the tests of the progress output we won't use values that don't fit into an int anyway. [1] start_progress() expects the total number as an uint64_t, that's why I chose the same type when declaring the variable holding the value given on the command line. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> [jpag: Debian unstable/ppc64 (big-endian)] Tested-By: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> [tz: Fedora s390x (big-endian)] Tested-By: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-19l10n: bg.po: Updated Bulgarian translation (4693)Libravatar Alexander Shopov1-2425/+2560
Synced with 2.24-rc0 Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2019-10-18completion: clarify installation instruction for zshLibravatar Maxim Belsky1-2/+3
The original comment does not describe type of ~/.zsh/_git explicitly and zsh does not warn or fail if a user create it as a dictionary. So unexperienced users could be misled by the original comment. There is a small update to clarify it. Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Maxim Belsky <public.belsky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-18Git 2.24-rc0Libravatar Junio C Hamano2-1/+18
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-18Merge branch 'rs/remote-curl-use-argv-array'Libravatar Junio C Hamano1-13/+9
Code cleanup. * rs/remote-curl-use-argv-array: remote-curl: use argv_array in parse_push()
2019-10-18Merge branch 'rs/column-use-utf8-strnwidth'Libravatar Junio C Hamano1-12/+1
Code cleanup. * rs/column-use-utf8-strnwidth: column: use utf8_strnwidth() to strip out ANSI color escapes
2019-10-18Merge branch 'rs/http-push-simplify'Libravatar Junio C Hamano1-4/+4
Code cleanup. * rs/http-push-simplify: http-push: simplify deleting a list item
2019-10-18Merge branch 'jj/stash-reset-only-toplevel'Libravatar Junio C Hamano3-3/+43
"git stash save" lost local changes to submodules, which has been corrected. * jj/stash-reset-only-toplevel: stash: avoid recursive hard reset on submodules
2019-10-18Merge branch 'bw/format-patch-o-create-leading-dirs'Libravatar Junio C Hamano4-2/+42
"git format-patch -o <outdir>" did an equivalent of "mkdir <outdir>" not "mkdir -p <outdir>", which is being corrected. * bw/format-patch-o-create-leading-dirs: format-patch: create leading components of output directory
2019-10-18Merge branch 'bb/compat-util-comment-fix'Libravatar Junio C Hamano1-1/+1
Code cleanup. * bb/compat-util-comment-fix: git-compat-util: fix documentation syntax
2019-10-18Merge branch 'bb/utf8-wcwidth-cleanup'Libravatar Junio C Hamano1-4/+2
Code cleanup. * bb/utf8-wcwidth-cleanup: utf8: use ARRAY_SIZE() in git_wcwidth()
2019-10-18Merge branch 'dl/allow-running-cocci-verbosely'Libravatar Junio C Hamano1-1/+2
Dev support update. * dl/allow-running-cocci-verbosely: Makefile: respect $(V) in %.cocci.patch target
2019-10-18Merge branch 'dl/compat-cleanup'Libravatar Junio C Hamano1-1/+1
Code formatting micronit fix. * dl/compat-cleanup: pthread.h: manually align parameter lists
2019-10-18Merge branch 'ta/t1308-typofix'Libravatar Junio C Hamano1-4/+4
Test fix. * ta/t1308-typofix: t1308-config-set: fix a test that has a typo
2019-10-18Merge branch 'js/doc-stash-save'Libravatar Junio C Hamano1-2/+3
Doc clarification. * js/doc-stash-save: doc(stash): clarify the description of `save`