summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-11-09doc: git-http-push: describe the refs as pattern pairsJean-Noël Avila1-7/+6
Each member of the pair is explained but they are not defined beforehand. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-09doc: uniformize <URL> placeholders' caseJean-Noël Avila8-20/+20
URL being an acronym, it deserves to be kept uppercase. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-09doc: use three dots for indicating repetition instead of starJean-Noël Avila2-2/+2
This is how it is specified in CodingGuidelines. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-09doc: git-ls-files: express options as optional alternativesJean-Noël Avila1-3/+3
That's how alternative options are expressed in general. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-09l10n: pl: 2.34.0 round 2Arusekk1-254/+251
Signed-off-by: Arusekk <arek_koz@o2.pl>
2021-11-08l10n: vi(5210t): Translation for v2.34.0 rd2Tran Ngoc Quan1-4239/+4588
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2021-11-07l10n: es: 2.34.0 round 2Christopher 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 translationJordi Mas1-6/+6
Signed-off-by: Jordi Mas <jmas@softcatala.org>
2021-11-06l10n: bg.po: Updated Bulgarian translation (5210t)Alexander Shopov1-4218/+4107
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2021-11-06Merge branch 'pt-PT' of github.com:git-l10n-pt-PT/git-poJiang Xin1-2189/+1528
* 'pt-PT' of github.com:git-l10n-pt-PT/git-po: l10n: pt_PT: cleaning duplicate translations (#2)
2021-11-06Merge branch 'l10n/zh_TW/211104' of github.com:l10n-tw/git-poJiang Xin1-4295/+4661
* 'l10n/zh_TW/211104' of github.com:l10n-tw/git-po: l10n: zh_TW.po: v2.34.0 round 2 (0 untranslated)
2021-11-05t/lib-git.sh: fix ACL-related permissions failureAdam Dinwoodie1-0/+1
As well as checking that the relevant functionality is available, the GPGSSH prerequisite check creates the SSH keys that are used by the test functions it gates. If these keys are created in a directory that has a default Access Control List, the key files can inherit those permissions. This can result in a scenario where the private keys are created successfully, so the prerequisite check passes and the tests are run, but the key files have permissions that are too permissive, meaning OpenSSH will refuse to load them and the tests will fail. To avoid this happening, before creating the keys, clear any default ACL set on the directory that will contain them. This step allowed to fail; if setfacl isn't present, that's a very likely indicator that the filesystem in question simply doesn't support default ACLs. Helped-by: Fabian Stelzer <fs@gigacodes.de> Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-05l10n: fr: v2.34.0 round 2Jean-Noël Avila1-815/+291
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
2021-11-05generate-cmdlist.sh: don't parse command-list.txt thriceÆvar Arnfjörð Bjarmason1-7/+10
Change the "define_categories()" and "define_category_names()" functions to take the already-parsed output of "category_list()" as an argument, which brings our number of passes over "command-list.txt" from three to two. Then have "category_list()" itself take the output of "command_list()" as an argument, bringing the number of times we parse the file to one. Compared to the pre-image this speeds us up quite a bit: $ git show HEAD~:generate-cmdlist.sh >generate-cmdlist.sh.old $ hyperfine --warmup 10 -L v ,.old 'sh generate-cmdlist.sh{v} command-list.txt' Benchmark #1: sh generate-cmdlist.sh command-list.txt Time (mean ± σ): 22.9 ms ± 0.3 ms [User: 15.8 ms, System: 9.6 ms] Range (min … max): 22.5 ms … 24.0 ms 125 runs Benchmark #2: sh generate-cmdlist.sh.old command-list.txt Time (mean ± σ): 30.1 ms ± 0.4 ms [User: 24.4 ms, System: 17.5 ms] Range (min … max): 29.5 ms … 32.3 ms 96 runs Summary 'sh generate-cmdlist.sh command-list.txt' ran 1.32 ± 0.02 times faster than 'sh generate-cmdlist.sh.old command-list.txt' Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-05generate-cmdlist.sh: replace "grep' invocation with a shell versionÆvar Arnfjörð Bjarmason2-5/+21
Replace the "grep" we run to exclude certain programs from the generated output with a pure-shell loop that strips out the comments, and sees if the "cmd" we're reading is on a list of excluded programs. This uses a trick similar to test_have_prereq() in test-lib-functions.sh. On my *nix system this makes things quite a bit slower compared to HEAD~: o 'sh generate-cmdlist.sh.old command-list.txt' ran 1.56 ± 0.11 times faster than 'sh generate-cmdlist.sh command-list.txt' 18.00 ± 0.19 times faster than 'sh generate-cmdlist.sh.master command-list.txt' But when I tried running generate-cmdlist.sh 100 times in CI I found that it helped across the board even on OSX & Linux. I tried testing it in CI with this ad-hoc few-liner: for i in $(seq -w 0 11 | sort -nr) do git show HEAD~$i:generate-cmdlist.sh >generate-cmdlist-HEAD$i.sh && git add generate-cmdlist* && cp t/t0000-generate-cmdlist.sh t/t00$i-generate-cmdlist.sh || : && perl -pi -e "s/HEAD0/HEAD$i/g" t/t00$i-generate-cmdlist.sh && git add t/t00*.sh done && git commit -m"generated it" Here HEAD~02 and the t0002* file refers to this change, and HEAD~03 and t0003* file to the preceding commit, the relevant results were: linux-gcc: [12:05:33] t0002-generate-cmdlist.sh .. ok 14 ms ( 0.00 usr 0.00 sys + 3.64 cusr 3.09 csys = 6.73 CPU) [12:05:30] t0003-generate-cmdlist.sh .. ok 32 ms ( 0.00 usr 0.00 sys + 2.66 cusr 1.81 csys = 4.47 CPU) osx-gcc: [11:58:04] t0002-generate-cmdlist.sh .. ok 80081 ms ( 0.02 usr 0.02 sys + 17.80 cusr 10.07 csys = 27.91 CPU) [11:58:16] t0003-generate-cmdlist.sh .. ok 92127 ms ( 0.02 usr 0.01 sys + 22.54 cusr 14.27 csys = 36.84 CPU) vs-test: [12:03:14] t0002-generate-cmdlist.sh .. ok 30 s ( 0.02 usr 0.00 sys + 13.14 cusr 26.19 csys = 39.35 CPU) [12:03:20] t0003-generate-cmdlist.sh .. ok 32 s ( 0.00 usr 0.02 sys + 13.25 cusr 26.10 csys = 39.37 CPU) I.e. even on *nix running 100 of these in a loop was up to ~2x faster in absolute runtime, I suspect it's due factors that are exacerbated in the CI, e.g. much slower process startup due to some platform limits, or a slower FS. The "cut -d" change here is because we're not emitting the 40-character aligned output anymore, i.e. we'll get the output from command_list() now, not an as-is line from command-list.txt. This also makes the parsing more reliable, as we could tweak the whitespace alignment without breaking this parser. Let's reword a now-inaccurate comment in "command-list.txt" describing that previous alignment limitation. We'll still need the "### command-list [...]" line due to the "Documentation/cmd-list.perl" logic added in 11c6659d85d (command-list: prepare machinery for upcoming "common groups" section, 2015-05-21). There was a proposed change subsequent to this one[3] which continued moving more logic into the "command_list() function, i.e. replaced the "cut | tr | grep" chain in "category_list()" with an argument to "command_list()". That change might have had a bit of an effect, but not as much as the preceding commit, so I decided to drop it. The relevant performance numbers from it were: linux-gcc: [12:05:33] t0001-generate-cmdlist.sh .. ok 13 ms ( 0.00 usr 0.00 sys + 3.33 cusr 2.78 csys = 6.11 CPU) [12:05:33] t0002-generate-cmdlist.sh .. ok 14 ms ( 0.00 usr 0.00 sys + 3.64 cusr 3.09 csys = 6.73 CPU) osx-gcc: [11:58:03] t0001-generate-cmdlist.sh .. ok 78416 ms ( 0.02 usr 0.01 sys + 11.78 cusr 6.22 csys = 18.03 CPU) [11:58:04] t0002-generate-cmdlist.sh .. ok 80081 ms ( 0.02 usr 0.02 sys + 17.80 cusr 10.07 csys = 27.91 CPU) vs-test: [12:03:20] t0001-generate-cmdlist.sh .. ok 34 s ( 0.00 usr 0.03 sys + 12.42 cusr 19.55 csys = 32.00 CPU) [12:03:14] t0002-generate-cmdlist.sh .. ok 30 s ( 0.02 usr 0.00 sys + 13.14 cusr 26.19 csys = 39.35 CPU) As above HEAD~2 and t0002* are testing the code in this commit (and the line is the same), but HEAD~1 and t0001* are testing that dropped change in [3]. 1. https://lore.kernel.org/git/cover-v2-00.10-00000000000-20211022T193027Z-avarab@gmail.com/ 2. https://lore.kernel.org/git/patch-v2-08.10-83318d6c0da-20211022T193027Z-avarab@gmail.com/ 3. https://lore.kernel.org/git/patch-v2-10.10-e10a43756d1-20211022T193027Z-avarab@gmail.com/ Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-05generate-cmdlist.sh: do not shell out to "sed"Jeff King1-11/+12
Replace the "sed" invocation in get_synopsis() with a pure-shell version. This speeds up generate-cmdlist.sh significantly. Compared to HEAD~ (old) and "master" we are, according to hyperfine(1): 'sh generate-cmdlist.sh command-list.txt' ran 12.69 ± 5.01 times faster than 'sh generate-cmdlist.sh.old command-list.txt' 18.34 ± 3.03 times faster than 'sh generate-cmdlist.sh.master command-list.txt' Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-05generate-cmdlist.sh: stop sorting category linesÆvar Arnfjörð Bjarmason1-6/+1
In a preceding commit we changed the print_command_list() loop to use printf's auto-repeat feature. Let's now get rid of get_category_line() entirely by not sorting the categories. This will change the output of the generated code from e.g.: - { "git-apply", N_("Apply a patch to files and/or to the index"), 0 | CAT_complete | CAT_plumbingmanipulators }, To: + { "git-apply", N_("Apply a patch to files and/or to the index"), 0 | CAT_plumbingmanipulators | CAT_complete }, I.e. the categories are no longer sorted, but as they're OR'd together it won't matter for the end result. This speeds up the generate-cmdlist.sh a bit. Comparing HEAD~ (old) and "master" to this code: 'sh generate-cmdlist.sh command-list.txt' ran 1.07 ± 0.33 times faster than 'sh generate-cmdlist.sh.old command-list.txt' 1.15 ± 0.36 times faster than 'sh generate-cmdlist.sh.master command-list.txt' Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-05generate-cmdlist.sh: replace for loop by printf's auto-repeat featureJohannes Sixt1-4/+1
This is just a small code reduction. There is a small probability that the new code breaks when the category list is empty. But that would be noticed during the compile step. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-05generate-cmdlist.sh: run "grep | sort", not "sort | grep"Ævar Arnfjörð Bjarmason1-2/+2
This doesn't matter for performance, but let's not include the empty lines in our sorting. This makes the intent of the code clearer. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-05generate-cmdlist.sh: don't call get_categories() from category_list()Ævar Arnfjörð Bjarmason1-3/+4
This isn't for optimization as the get_categories() is a purely shell function, but rather for ease of readability, let's just inline these two lines. We'll be changing this code some more in subsequent commits to make this worth it. Rename the get_categories() function to get_category_line(), since that's what it's doing now. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-05generate-cmdlist.sh: spawn fewer processesJohannes Sixt1-4/+3
The function get_categories() is invoked in a loop over all commands. As it runs several processes, this takes an awful lot of time on Windows. To reduce the number of processes, move the process that filters empty lines to the other invoker of the function, where it is needed. The invocation of get_categories() in the loop does not need the empty line filtered away because the result is word-split by the shell, which eliminates the empty line automatically. Furthermore, use sort -u instead of sort | uniq to remove yet another process. [Ævar: on Linux this seems to speed things up a bit, although with hyperfine(1) the results are fuzzy enough to land within the confidence interval]: $ git show HEAD~:generate-cmdlist.sh >generate-cmdlist.sh.old $ hyperfine --warmup 1 -L s ,.old -p 'make clean' 'sh generate-cmdlist.sh{s} command-list.txt' Benchmark #1: sh generate-cmdlist.sh command-list.txt Time (mean ± σ): 371.3 ms ± 64.2 ms [User: 430.4 ms, System: 72.5 ms] Range (min … max): 320.5 ms … 517.7 ms 10 runs Benchmark #2: sh generate-cmdlist.sh.old command-list.txt Time (mean ± σ): 489.9 ms ± 185.4 ms [User: 724.7 ms, System: 141.3 ms] Range (min … max): 346.0 ms … 885.3 ms 10 runs Summary 'sh generate-cmdlist.sh command-list.txt' ran 1.32 ± 0.55 times faster than 'sh generate-cmdlist.sh.old command-list.txt' Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-05generate-cmdlist.sh: trivial whitespace changeÆvar Arnfjörð Bjarmason1-1/+1
Add " " before a "|" at the end of a line in generate-cmdlist.sh for consistency with other code in the file. Some of the surrounding code will be modified in subsequent commits. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-05command-list.txt: sort with "LC_ALL=C sort"Ævar Arnfjörð Bjarmason1-10/+10
We should keep these files sorted in the C locale, e.g. in the C locale the order is: git-check-mailmap git-check-ref-format git-checkout But under en_US.UTF-8 it's: git-check-mailmap git-checkout git-check-ref-format In a subsequent commit I'll change generate-cmdlist.sh to use C sort order, and without this change we'd be led to believe that that change caused a meaningful change in the output, so let's do this as a separate step, right now the generate-cmdlist.sh script just uses the order found in this file. Note that this refers to the sort order of the lines in command-list.txt, a subsequent commit will also change how we treat the sort order of the "category" fields, but that's unrelated to this change. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-05test_bitmap_hashes(): handle repository without bitmapsJeff King1-1/+1
If prepare_bitmap_git() returns NULL (one easy-to-trigger cause being that the repository does not have bitmaps at all), then we'll segfault accessing bitmap_git->hashes: $ t/helper/test-tool bitmap dump-hashes Segmentation fault We should treat this the same as a repository with bitmaps but no name-hashes, and quietly produce an empty output. The later call to free_bitmap_index() in the cleanup label is OK, as it treats a NULL pointer as a noop. This isn't a big deal in practice, as this function is intended for and used only by test-tool. It's probably worth fixing to avoid confusion, but not worth adding coverage for this to the test suite. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-05Merge branch 'vk/readme-typo'Pratyush Yadav1-1/+1
Add missing punctuation. * vk/readme-typo: git-gui: Fix a typo in README
2021-11-05git-gui: Fix a typo in READMEVipul Kumar1-1/+1
Add a missing punctuation. Signed-off-by: Vipul Kumar <kumar@onenetbeyond.org> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>
2021-11-05Merge branch 'po-id' of github.com:bagasme/git-poJiang Xin1-308/+318
* 'po-id' of github.com:bagasme/git-po: l10n: po-id for 2.34 (round 2)
2021-11-05l10n: po-id for 2.34 (round 2)Bagas Sanjaya1-308/+318
Translate following new components: * gpg-interface.c * send-pack.c * fetch-pack.c * upload-pack.c Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
2021-11-05l10n: zh_TW.po: v2.34.0 round 2 (0 untranslated)pan934121-4295/+4661
Signed-off-by: pan93412 <pan93412@gmail.com>
2021-11-05Merge branch 'master' of github.com:nafmo/git-l10n-svJiang Xin1-4207/+4575
* 'master' of github.com:nafmo/git-l10n-sv: l10n: sv.po: Update Swedish translation (5210t0f0u)
2021-11-05Merge branch 'fz/po-zh_CN' of github.com:fangyi-zhou/git-poJiang Xin1-232/+232
* 'fz/po-zh_CN' of github.com:fangyi-zhou/git-po: l10n: zh_CN: 2.34.0 Round 2
2021-11-04l10n: sv.po: Update Swedish translation (5210t0f0u)Peter Krefting1-4207/+4575
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2021-11-04strbuf_addftime(): handle "%s" manuallyJeff King5-3/+20
The strftime() function has a non-standard "%s" extension, which prints the number of seconds since the epoch. But the "struct tm" we get has already been adjusted for a particular time zone; going back to an epoch time requires knowing that zone offset. Since strftime() doesn't take such an argument, round-tripping to a "struct tm" and back to the "%s" format may produce the wrong value (off by tz_offset seconds). Since we're already passing in the zone offset courtesy of c3fbf81a85 (strbuf: let strbuf_addftime handle %z and %Z itself, 2017-06-15), we can use that same value to adjust our epoch seconds accordingly. Note that the description above makes it sound like strftime()'s "%s" is useless (and really, the issue is shared by mktime(), which is what strftime() would use under the hood). But it gets the two cases for which it's designed correct: - the result of gmtime() will have a zero offset, so no adjustment is necessary - the result of localtime() will be offset by the local zone offset, and mktime() and strftime() are defined to assume this offset when converting back (there's actually some magic here; some implementations record this in the "struct tm", but we can't portably access or manipulate it. But they somehow "know" whether a "struct tm" is from gmtime() or localtime()). This latter point means that "format-local:%s" actually works correctly already, because in that case we rely on the system routines due to 6eced3ec5e (date: use localtime() for "-local" time formats, 2017-06-15). Our problem comes when trying to show times in the author's zone, as the system routines provide no mechanism for converting in non-local zones. So in those cases we have a "struct tm" that came from gmtime(), but has been manipulated according to our offset. The tests cover the broken round-trip by formatting "%s" for a time in a non-system timezone. We use the made-up "+1234" here, which has two advantages. One, we know it won't ever be the real system zone (and so we're actually testing a case that would break). And two, since it has a minute component, we're testing the full decoding of the +HHMM zone into a number of seconds. Likewise, we test the "-1234" variant to make sure there aren't any sign mistakes. There's one final test, which covers "format-local:%s". As noted, this already passes, but it's important to check that we didn't regress this case. In particular, the caller in show_date() is relying on localtime() to have done the zone adjustment, independent of any tz_offset we compute ourselves. These should match up, since our local_tzoffset() is likewise built around localtime(). But it would be easy for a caller to forget to pass in a correct tz_offset to strbuf_addftime(). Fortunately show_date() does this correctly (it has to because of the existing handling of %z), and the test continues to pass. So this one is just future-proofing against a change in our assumptions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-04A few fixes before -rc2Junio C Hamano1-0/+7
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-04Sync with maintJunio C Hamano0-0/+0
2021-11-04Merge branch 'vd/pthread-setspecific-g11-fix' into maintJunio C Hamano1-1/+1
One CI task based on Fedora image noticed a not-quite-kosher consturct recently, which has been corrected. * vd/pthread-setspecific-g11-fix: async_die_is_recursing: work around GCC v11.x issue on Fedora
2021-11-04Merge branch 'ma/doc-git-version' into maintJunio C Hamano1-1/+1
Typofix. * ma/doc-git-version: git.txt: fix typo
2021-11-04Merge branch 'pw/rebase-r-fixes' into maintJunio C Hamano2-1/+32
Regression fix. * pw/rebase-r-fixes: rebase -i: fix rewording with --committer-date-is-author-date
2021-11-04Merge branch 'jk/log-warn-on-bogus-encoding' into maintJunio C Hamano3-14/+3
Squelch over-eager warning message added during this cycle. * jk/log-warn-on-bogus-encoding: log: document --encoding behavior on iconv() failure Revert "logmsg_reencode(): warn when iconv() fails"
2021-11-04Merge branch 'vd/pthread-setspecific-g11-fix'Junio C Hamano1-1/+1
One CI task based on Fedora image noticed a not-quite-kosher consturct recently, which has been corrected. * vd/pthread-setspecific-g11-fix: async_die_is_recursing: work around GCC v11.x issue on Fedora
2021-11-04Merge branch 'rd/http-backend-code-simplification'Junio C Hamano1-3/+1
Code simplification. * rd/http-backend-code-simplification: http-backend: remove a duplicated code branch
2021-11-04Merge branch 'ar/no-verify-doc'Junio C Hamano3-4/+14
Doc update. * ar/no-verify-doc: Document positive variant of commit and merge option "--no-verify"
2021-11-04Merge branch 'ar/fix-git-pull-no-verify'Junio C Hamano2-0/+30
"git pull --no-verify" did not affect the underlying "git merge". * ar/fix-git-pull-no-verify: pull: honor --no-verify and do not call the commit-msg hook
2021-11-04ci: disallow directional formattingJohannes Schindelin2-0/+28
As described in https://trojansource.codes/trojan-source.pdf, it is possible to abuse directional formatting (a feature of Unicode) to deceive human readers into interpreting code differently from compilers. For example, an "if ()" expression could be enclosed in a comment, but rendered as if it was outside of that comment. In effect, this could fool a reviewer into misinterpreting the code flow as benign when it is not. It is highly unlikely that Git's source code wants to contain such directional formatting in the first place, so let's just disallow it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-04l10n: zh_CN: 2.34.0 Round 2Fangyi Zhou1-232/+232
Signed-off-by: Fangyi Zhou <me@fangyi.io>
2021-11-04l10n: tr: v2.34.0 round 2Emir Sarı1-240/+246
Signed-off-by: Emir Sarı <bitigchi@me.com>
2021-11-03async_die_is_recursing: work around GCC v11.x issue on FedoraVictoria Dye1-1/+1
This fix corrects an issue found in the `dockerized(pedantic, fedora)` CI build, first appearing after the introduction of a new version of the Fedora docker image version. This image includes a version of `glibc` with the attribute `__attr_access_none` added to `pthread_setspecific` [1], the implementation of which only exists for GCC 11.X - the version included in the Fedora image. The attribute requires that the pointer provided in the second argument of `pthread_getspecific` must, if not NULL, be a pointer to a valid object. In the usage in `async_die_is_recursing`, `(void *)1` is not valid, causing the error. This fix imitates a workaround added in SELinux [2] by using the pointer to the static `async_die_counter` itself as the second argument to `pthread_setspecific`. This guaranteed non-NULL, valid pointer matches the intent of the current usage while not triggering the build error. [1] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a1561c3bbe8 [2] https://lore.kernel.org/all/20211021140519.6593-1-cgzones@googlemail.com/ Co-authored-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Victoria Dye <vdye@github.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-04l10n: git.pot: v2.34.0 round 2 (3 new, 3 removed)Jiang Xin1-230/+230
Generate po/git.pot from v2.34.0-rc1 for git v2.34.0 l10n round 2. Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2021-11-04Merge branch 'master' of github.com:git/gitJiang Xin25-85/+416
* 'master' of github.com:git/git: Git 2.34-rc1 rebase -i: fix rewording with --committer-date-is-author-date dir: fix directory-matching bug gpg-interface: avoid buffer overrun in parse_ssh_output() gpg-interface: handle missing " with " gracefully in parse_ssh_output() A few more topics before -rc1 i18n: fix typos found during l10n for git 2.34.0 t5310: drop lib-bundle.sh include format-patch (doc): clarify --base=auto gc: perform incremental repack when implictly enabled fsck: verify multi-pack-index when implictly enabled fsck: verify commit graph when implicitly enabled grep/pcre2: fix an edge case concerning ascii patterns and UTF-8 data commit-graph: don't consider "replace" objects with "verify" commit-graph tests: fix another graph_git_two_modes() helper commit-graph tests: fix error-hiding graph_git_two_modes() helper pretty: colorize pattern matches in commit messages grep: refactor next_match() and match_one_pattern() for external use
2021-11-04Merge branch 'fz/po-zh_CN' of github.com:fangyi-zhou/git-poJiang Xin1-4165/+4566
* 'fz/po-zh_CN' of github.com:fangyi-zhou/git-po: l10n: zh-CN: v2.34.0 round 1