summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-11-23CI: rename the "Linux32" job to lower-case "linux32"Libravatar Ævar Arnfjörð Bjarmason5-5/+6
As a follow-up to the preceding commit's shortening of CI job names, rename the only job that starts with an upper-case letter to be consistent with the rest. It was added in 88dedd5e72c (Travis: also test on 32-bit Linux, 2017-03-05). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-23CI: use shorter names that fit in UX tooltipsLibravatar Ævar Arnfjörð Bjarmason2-2/+10
Change the names used for the GitHub CI workflows to be short enough to (mostly) fit in the pop-up tool-tips that GitHub shows in the commit view. I.e. when mouse-clicking on the passing or failing check-mark next to the commit subject. These names are seemingly truncated to 17-20 characters followed by three dots ("..."). Since a "CI/PR / " prefix is added to them the job names looked like this before (windows-test and vs-test jobs omitted): CI/PR / ci-config (p... CI/PR / windows-buil... CI/PR / vs-build (pu... CI/PR / regular (lin... CI/PR / regular (lin... CI/PR / regular (os... CI/PR / regular (os... CI/PR / regular (lin... CI/PR / regular (lin... CI/PR / dockerized (... CI/PR / dockerized (... CI/PR / dockerized (... CI/PR / static-anal... CI/PR / sparse (pu... CI/PR / documenta... By omitting the "/PR" from the top-level name, and pushing the $jobname to the front we'll now instead get: CI / config (push) CI / win build (push... CI / win+VS build (... CI / linux-clang (ub... CI / linux-gcc (ubun... CI / osx-clang (osx)... CI / osx-gcc (osx) (... CI / linux-gcc-defau... CI / linux-leaks (ub... CI / linux-musl (alp... CI / Linux32 (daald/... CI / pedantic (fedor... CI / static-analysis... CI / sparse (push)... CI / documentation We then have no truncation in the expanded view. See [1] for how it looked before, [2] for a currently visible CI run using this commit, and [3] for the GitHub workflow syntax involved being changed here. Let's also use the existing "pool" field as before. It's occasionally useful to know we're running on say ubuntu v.s. fedora. The "-latest" suffix is useful to some[4], and since it's now at the end it doesn't hurt readability in the short view compared to saying "ubuntu" or "macos". 1. https://github.com/git/git/tree/master/ 2. https://github.com/avar/git/tree/avar/ci-rm-travis-cleanup-ci-names-3 3. https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions 3. https://lore.kernel.org/git/d9b07ca5-b58d-a535-d25b-85d7f12e6295@github.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-23CI: remove Travis CI supportLibravatar Ævar Arnfjörð Bjarmason7-118/+7
Remove support for running the CI in travis. The last builds in it are from 5 months ago[1] (as of 2021-11-19), and our documentation has referred to GitHub CI instead since f003a91f5c5 (SubmittingPatches: replace discussion of Travis with GitHub Actions, 2021-07-22). We'll now run the "t9810 t9816" and tests on OSX. We didn't before, as we'd carried the Travis exclusion of them forward from 522354d70f4 (Add Travis CI support, 2015-11-27). Let's hope whatever issue there was with them was either Travis specific, or fixed since then (I'm not sure). The "apt-add-repository" invocation (which we were doing in GitHub CI) isn't needed, it was another Travis-only case that was carried forward into more general code. See 0f0c51181df (travis-ci: install packages in 'ci/install-dependencies.sh', 2018-11-01). Remove the "linux-gcc-4.8" job added in fb9d7431cf4 (travis-ci: build with GCC 4.8 as well, 2019-07-18), it only ran in Travis CI. 1. https://travis-ci.org/github/git/git/builds Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-14Git 2.34Libravatar Junio C Hamano2-5/+3
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-14Merge tag 'l10n-2.34.0-rnd3.1' of git://github.com/git-l10n/git-poLibravatar Junio C Hamano17-61128/+63643
l10n-2.34.0-rnd3.1 * tag 'l10n-2.34.0-rnd3.1' of git://github.com/git-l10n/git-po: (38 commits) l10n: pl: 2.34.0 round 3 l10n: it: fix typos found by git-po-helper l10n: ko: fix typos found by git-po-helper l10n: Update Catalan translation l10n: po-id for 2.34 (round 3) l10n: bg.po: Updated Bulgarian translation (5211t) l10n: de.po: Update German translation for Git v2.34.0 l10n: sv.po: Update Swedish translation (5211t0f0) l10n: vi(5211t): Translation for v2.34.0 rd3 l10n: zh_TW.po: v2.34.0 round 3 (0 untranslated) l10n: fr: v2.34.0 rnd 3 l10n: tr: v2.34.0 round 3 l10n: zh_CN: v2.34.0 round 3 l10n: git.pot: v2.34.0 round 3 (1 new) l10n: pl: 2.34.0 round 2 l10n: vi(5210t): Translation for v2.34.0 rd2 l10n: es: 2.34.0 round 2 l10n: Update Catalan translation l10n: bg.po: Updated Bulgarian translation (5210t) l10n: fr: v2.34.0 round 2 ...
2021-11-14l10n: pl: 2.34.0 round 3Libravatar Arusekk1-92/+96
Signed-off-by: Arusekk <arek_koz@o2.pl>
2021-11-14l10n: it: fix typos found by git-po-helperLibravatar Jiang Xin1-3/+3
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2021-11-14l10n: ko: fix typos found by git-po-helperLibravatar Jiang Xin1-5/+5
When checking typos in file "po/ko.po", "git-po-helper" reports lots of false positives because there are no spaces between ASCII and Korean characters. After applied commit adee197 "(dict: add smudge table for Korean language, 2021-11-11)" of "git-l10n/git-po-helper" to suppress these false positives, some easy-to-fix typos are found and fixed. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2021-11-13l10n: Update Catalan translationLibravatar Jordi Mas1-52/+41
Signed-off-by: Jordi Mas <jmas@softcatala.org>
2021-11-13Merge branch 'po-id' of github.com:bagasme/git-poLibravatar Jiang Xin1-307/+196
* 'po-id' of github.com:bagasme/git-po: l10n: po-id for 2.34 (round 3)
2021-11-13l10n: po-id for 2.34 (round 3)Libravatar Bagas Sanjaya1-307/+196
- Translate following new components: * merge.c * rebase-interactive.c * rebase.c * midx.c - Clean up obsolete translations Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
2021-11-13Merge branch 'master' of github.com:ruester/git-po-deLibravatar Jiang Xin1-4264/+4119
* 'master' of github.com:ruester/git-po-de: l10n: de.po: Update German translation for Git v2.34.0
2021-11-12Merge branch 'js/trace2-raise-format-version'Libravatar Junio C Hamano2-3/+3
When we added a new event type to trace2 event stream, we forgot to raise the format version number, which has been corrected. * js/trace2-raise-format-version: trace2: increment event format version
2021-11-12Merge branch 'ab/fsck-unexpected-type'Libravatar Junio C Hamano3-4/+12
Regression fix. * ab/fsck-unexpected-type: object-file: free(*contents) only in read_loose_object() caller object-file: fix SEGV on free() regression in v2.34.0-rc2
2021-11-12Merge branch 'ps/connectivity-optim'Libravatar Junio C Hamano4-48/+1
Regression fix. * ps/connectivity-optim: Revert "connected: do not sort input revisions"
2021-11-12l10n: bg.po: Updated Bulgarian translation (5211t)Libravatar Alexander Shopov1-101/+104
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2021-11-12l10n: de.po: Update German translation for Git v2.34.0Libravatar Matthias Rüster1-4264/+4119
Signed-off-by: Matthias Rüster <matthias.ruester@gmail.com> Reviewed-by: Ralf Thielow <ralf.thielow@gmail.com> Reviewed-by: Phillip Szelat <phillip.szelat@gmail.com>
2021-11-11trace2: increment event format versionLibravatar Josh Steadmon2-3/+3
In 64bc752 (trace2: add trace2_child_ready() to report on background children, 2021-09-20), we added a new "child_ready" event. In Documentation/technical/api-trace2.txt, we promise that adding a new event type will result in incrementing the trace2 event format version number, but this was not done. Correct this in code & docs. Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-11l10n: sv.po: Update Swedish translation (5211t0f0)Libravatar Peter Krefting1-93/+97
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2021-11-11object-file: free(*contents) only in read_loose_object() callerLibravatar Ævar Arnfjörð Bjarmason2-6/+4
In the preceding commit a free() of uninitialized memory regression in 96e41f58fe1 (fsck: report invalid object type-path combinations, 2021-10-01) was fixed, but we'd still have an issue with leaking memory from fsck_loose(). Let's fix that issue too. That issue was introduced in my 31deb28f5e0 (fsck: don't hard die on invalid object types, 2021-10-01). It can be reproduced under SANITIZE=leak with the test I added in 093fffdfbec (fsck tests: add test for fsck-ing an unknown type, 2021-10-01): ./t1450-fsck.sh --run=84 -vixd In some sense it's not a problem, we lost the same amount of memory in terms of things malloc'd and not free'd. It just moved from the "still reachable" to "definitely lost" column in valgrind(1) nomenclature[1], since we'd have die()'d before. But now that we don't hard die() anymore in the library let's properly free() it. Doing so makes this code much easier to follow, since we'll now have one function owning the freeing of the "contents" variable, not two. For context on that memory management pattern the read_loose_object() function was added in f6371f92104 (sha1_file: add read_loose_object() function, 2017-01-13) and subsequently used in c68b489e564 (fsck: parse loose object paths directly, 2017-01-13). The pattern of it being the task of both sides to free() the memory has been there in this form since its inception. 1. https://valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-11Revert "connected: do not sort input revisions"Libravatar Junio C Hamano4-48/+1
This reverts commit f45022dc2fd692fd024f2eb41a86a66f19013d43, as this is like breakage in the traversal more likely. In a history with 10 single strand of pearls, 1-->2-->3--...->7-->8-->9-->10 asking "rev-list --unsorted-input 1 10 --not 9 8 7 6 5 4" fails to paint the bottom 1 uninteresting as the traversal stops, without completing the propagation of uninteresting bit starting at 4 down through 3 and 2 to 1.
2021-11-11object-file: fix SEGV on free() regression in v2.34.0-rc2Libravatar Ævar Arnfjörð Bjarmason2-0/+10
Fix a regression introduced in my 96e41f58fe1 (fsck: report invalid object type-path combinations, 2021-10-01). When fsck-ing blobs larger than core.bigFileThreshold, we'd free() a pointer to uninitialized memory. This issue would have been caught by SANITIZE=address, but since it involves core.bigFileThreshold, none of the existing tests in our test suite covered it. Running them with the "big_file_threshold" in "environment.c" changed to say "6" would have shown this failure, but let's add a dedicated test for this scenario based on Han Xin's report[1]. The bug was introduced between v9 and v10[2] of the fsck series merged in 061a21d36d8 (Merge branch 'ab/fsck-unexpected-type', 2021-10-25). 1. https://lore.kernel.org/git/20211111030302.75694-1-hanxin.hx@alibaba-inc.com/ 2. https://lore.kernel.org/git/cover-v10-00.17-00000000000-20211001T091051Z-avarab@gmail.com/ Reported-by: Han Xin <chiyutianyi@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-11l10n: vi(5211t): Translation for v2.34.0 rd3Libravatar Tran Ngoc Quan1-101/+107
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2021-11-11Merge branch 'l10n/zh_TW/211111' of github.com:l10n-tw/git-poLibravatar Jiang Xin1-93/+97
* 'l10n/zh_TW/211111' of github.com:l10n-tw/git-po: l10n: zh_TW.po: v2.34.0 round 3 (0 untranslated)
2021-11-11Merge branch 'fr_v2.34.0_rnd3' of github.com:jnavila/gitLibravatar Jiang Xin1-93/+97
* 'fr_v2.34.0_rnd3' of github.com:jnavila/git: l10n: fr: v2.34.0 rnd 3
2021-11-11Merge branch 'tr-2-34-r3' of github.com:bitigchi/git-poLibravatar Jiang Xin1-93/+97
* 'tr-2-34-r3' of github.com:bitigchi/git-po: l10n: tr: v2.34.0 round 3
2021-11-10A few hotfixesLibravatar Junio C Hamano1-7/+20
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-10Merge branch 'jk/ssh-signing-fix'Libravatar Junio C Hamano1-0/+6
Reject OpenSSH 8.7 whose "ssh-keygen -Y find-principals" is unusable from running the ssh signature tests. * jk/ssh-signing-fix: t/lib-gpg: avoid broken versions of ssh-keygen
2021-11-10Merge branch 'js/simple-ipc-cygwin-socket-fix'Libravatar Junio C Hamano1-0/+22
The way Cygwin emulates a unix-domain socket, on top of which the simple-ipc mechanism is implemented, can race with the program on the other side that wants to use the socket, and briefly make it appear as a regular file before lstat(2) starts reporting it as a socket. We now have a workaround on the side that connects to a unix domain socket. * js/simple-ipc-cygwin-socket-fix: simple-ipc: work around issues with Cygwin's Unix socket emulation
2021-11-10Merge branch 'ds/no-usable-cron-on-macos'Libravatar Junio C Hamano1-6/+21
"git maintenance run" learned to use system supplied scheduler backend, but cron on macOS turns out to be unusable for this purpose. * ds/no-usable-cron-on-macos: maintenance: disable cron on macOS
2021-11-10Merge branch 'jc/fix-pull-ff-only-when-already-up-to-date'Libravatar Junio C Hamano2-2/+43
"git pull --ff-only" and "git pull --rebase --ff-only" should make it a no-op to attempt pulling from a remote that is behind us, but instead the command errored out by saying it was impossible to fast-forward, which may technically be true, but not a useful thing to diagnose as an error. This has been corrected. * jc/fix-pull-ff-only-when-already-up-to-date: pull: --ff-only should make it a noop when already-up-to-date
2021-11-11l10n: zh_TW.po: v2.34.0 round 3 (0 untranslated)Libravatar Yi-Jyun Pan1-93/+97
Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com>
2021-11-10t/lib-gpg: avoid broken versions of ssh-keygenLibravatar Jeff King1-0/+6
The "-Y find-principals" option of ssh-keygen seems to be broken in Debian's openssh-client 1:8.7p1-1, whereas it works fine in 1:8.4p1-5. This causes several failures for GPGSSH tests. We fulfill the prerequisite because generating the keys works fine, but actually verifying a signature causes results ranging from bogus results to ssh-keygen segfaulting. We can find the broken version during the prereq check by feeding it empty input. This should result in it complaining to stderr, but in the broken version it triggers the segfault, causing the GPGSSH tests to be skipped. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-10l10n: fr: v2.34.0 rnd 3Libravatar Jean-Noël Avila1-93/+97
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
2021-11-10maintenance: disable cron on macOSLibravatar Derrick Stolee1-6/+21
In eba1ba9 (maintenance: `git maintenance run` learned `--scheduler=<scheduler>`, 2021-09-04), we introduced the ability to specify a scheduler explicitly. This led to some extra checks around whether an alternative scheduler was available. This added the functionality of removing background maintenance from schedulers other than the one selected. On macOS, cron is technically available, but running 'crontab' triggers a UI prompt asking for special permissions. This is the major reason why launchctl is used as the default scheduler. The is_crontab_available() method triggers this UI prompt, causing user disruption. Remove this disruption by using an #ifdef to prevent running crontab this way on macOS. This has the unfortunate downside that if a user manually selects cron via the '--scheduler' option, then adjusting the scheduler later will not remove the schedule from cron. The '--scheduler' option ignores the is_available checks, which is how we can get into this situation. Extract the new check_crontab_process() method to avoid making the 'child' variable unused on macOS. The method is marked MAYBE_UNUSED because it has no callers on macOS. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-10l10n: tr: v2.34.0 round 3Libravatar Emir Sarı1-93/+97
Signed-off-by: Emir Sarı <bitigchi@me.com>
2021-11-10simple-ipc: work around issues with Cygwin's Unix socket emulationLibravatar Johannes Schindelin1-0/+22
Cygwin emulates Unix sockets by writing files with custom contents and then marking them as system files. The tricky problem is that while the file is written and its `system` bit is set, it is still identified as a file. This caused test failures when Git is too fast looking for the Unix sockets and then complains that there is a plain file in the way. Let's work around this by adding a delayed retry loop, specifically for Cygwin. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Tested-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-10l10n: zh_CN: v2.34.0 round 3Libravatar Fangyi Zhou1-94/+98
Signed-off-by: Fangyi Zhou <me@fangyi.io>
2021-11-10Merge branch 'master' of github.com:alshopov/git-poLibravatar Jiang Xin1-4218/+4107
* 'master' of github.com:alshopov/git-po: l10n: bg.po: Updated Bulgarian translation (5210t)
2021-11-10l10n: git.pot: v2.34.0 round 3 (1 new)Libravatar Jiang Xin1-92/+96
Generate po/git.pot from v2.34.0-rc2 for git v2.34.0 l10n round 3. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2021-11-10Merge branch 'master' of github.com:git/gitLibravatar Jiang Xin12-20/+65
* 'master' of github.com:git/git: Git 2.34-rc2 parse-options.[ch]: revert use of "enum" for parse_options() t/lib-git.sh: fix ACL-related permissions failure A few fixes before -rc2 async_die_is_recursing: work around GCC v11.x issue on Fedora Document positive variant of commit and merge option "--no-verify" pull: honor --no-verify and do not call the commit-msg hook http-backend: remove a duplicated code branch
2021-11-09Git 2.34-rc2Libravatar Junio C Hamano2-2/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-09Merge branch 'ab/parse-options-cleanup'Libravatar Junio C Hamano2-10/+9
Last minute fix to the update already in 'master'. * ab/parse-options-cleanup: parse-options.[ch]: revert use of "enum" for parse_options()
2021-11-09Merge branch 'ad/ssh-signing-testfix'Libravatar Junio C Hamano1-0/+1
Fix ssh-signing test to work on a platform where the default ACL is overly loose to upset OpenSSH (reported on an installation of Cygwin). * ad/ssh-signing-testfix: t/lib-git.sh: fix ACL-related permissions failure
2021-11-09parse-options.[ch]: revert use of "enum" for parse_options()Libravatar Ævar Arnfjörð Bjarmason2-10/+9
Revert the parse_options() prototype change in my recent 352e761388b (parse-options.[ch]: consistently use "enum parse_opt_result", 2021-10-08) was incorrect. The parse_options() function returns the number of argc elements that haven't been processed, not "enum parse_opt_result". Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-09l10n: pl: 2.34.0 round 2Libravatar Arusekk1-254/+251
Signed-off-by: Arusekk <arek_koz@o2.pl>
2021-11-08l10n: vi(5210t): Translation for v2.34.0 rd2Libravatar Tran Ngoc Quan1-4239/+4588
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2021-11-07l10n: es: 2.34.0 round 2Libravatar Christopher Diaz Riveros1-4579/+5004
Signed-off-by: Christopher Diaz Riveros <christopher.diaz.riv@gmail.com> Signed-off-by: Omar Olivares <omar@olivares.cl> Signed-off-by: Jaime Marquínez Ferrándiz <jaime.marquinez.ferrandiz@fastmail.net> Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
2021-11-06l10n: Update Catalan translationLibravatar Jordi Mas1-6/+6
Signed-off-by: Jordi Mas <jmas@softcatala.org>
2021-11-06l10n: bg.po: Updated Bulgarian translation (5210t)Libravatar Alexander Shopov1-4218/+4107
Signed-off-by: Alexander Shopov <ash@kambanaria.org>