summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-11-13SubmittingPatches: fix Asciidoc syntax in "GitHub CI" sectionPhilippe Blain1-2/+2
A superfluous ']' was added to the title of the GitHub CI section in f003a91f5c (SubmittingPatches: replace discussion of Travis with GitHub Actions, 2021-07-22). Remove it. While at it, format the URL for a GitHub user's workflow runs of Git between backticks, since if not Asciidoc formats only the first part, "https://github.com/<Your", as a link, which is not very useful. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-14l10n: ko: fix typos found by git-po-helperJiang 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 translationJordi Mas1-52/+41
Signed-off-by: Jordi Mas <jmas@softcatala.org>
2021-11-13Merge branch 'po-id' of github.com:bagasme/git-poJiang 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)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-deJiang 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'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'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'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)Alexander Shopov1-101/+104
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2021-11-12l10n: de.po: Update German translation for Git v2.34.0Matthias 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 versionJosh 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-11protocol-v2.txt: align delim-pkt spec with usageCalvin Wan1-3/+3
The current protocol EBNF allows command-request to end with the capability list, if no command specific arguments follow, but the protocol requires that after the capability list, there must be a delim-pkt regardless of the number of command specific arguments. Fixed the EBNF to match. Both JGit and libgit2's implementation has the delim-pkt as mandatory. JGit's code is not publicly linkable, but libgit2 is linked below[1]. As for currently implemented commands on v2 (ls-ref and fetch), the delim packet is already being passed through [1]: https://github.com/libgit2/libgit2/blob/main/src/transports/git.c Reported-by: Ivan Frade <ifrade@google.com> Signed-off-by: Calvin Wan <calvinwan@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-11l10n: sv.po: Update Swedish translation (5211t0f0)Peter Krefting1-93/+97
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2021-11-11object-file: free(*contents) only in read_loose_object() callerÆ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"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-rc2Æ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-11http-fetch: redact url on die() messageIvan Frade1-2/+12
http-fetch prints the URL after failing to fetch it. This can be confusing to users (they cannot really do anything with it), and they can share by accident a sensitive URL (e.g. with credentials) while looking for help. Redact the URL unless the GIT_TRACE_REDACT variable is set to false. This mimics the redaction of other sensitive information in git, like the Authorization header in HTTP. Fix also capitalization of previous die() message (must start in lowercase). Signed-off-by: Ivan Frade <ifrade@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-11fetch-pack: redact packfile urls in tracesIvan Frade5-3/+99
In some setups, packfile uris act as bearer token. It is not recommended to expose them plainly in logs, although in special circunstances (e.g. debug) it makes sense to write them. Redact the packfile URL paths by default, unless the GIT_TRACE_REDACT variable is set to false. This mimics the redacting of the Authorization header in HTTP. Signed-off-by: Ivan Frade <ifrade@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-11packfile: avoid overflowing shift during decodeJonathan Tan1-1/+1
unpack_object_header_buffer() attempts to protect against overflowing left shifts, but the limit of the shift amount should not be the size of the variable being shifted. It should be the size minus the size of its contents. Fix that accordingly. This was noticed at $DAYJOB by a fuzzer running internally. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-11l10n: vi(5211t): Translation for v2.34.0 rd3Tran 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-poJiang 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/gitJiang 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-poJiang Xin1-93/+97
* 'tr-2-34-r3' of github.com:bitigchi/git-po: l10n: tr: v2.34.0 round 3
2021-11-10parse-options.c: use "enum parse_opt_result" for parse_nodash_opt()Ævar Arnfjörð Bjarmason1-3/+4
Change the parse_nodash_opt() function to use "enum parse_opt_result". In 352e761388b (parse-options.[ch]: consistently use "enum parse_opt_result", 2021-10-08) its only caller parse_options_step() started using that return type, and the get_value() which will be called and return from it uses the same enum. Let's do the same here so that this function always returns an "enum parse_opt_result" value. We could go for either PARSE_OPT_HELP (-2) or PARSE_OPT_ERROR (-1) here. The reason we ended up with "-2" is that in code added in 07fe54db3cd (parse-opt: do not print errors on unknown options, return "-2" instead., 2008-06-23) we used that value in a meaningful way. Then in 51a9949eda7 (parseopt: add PARSE_OPT_NODASH, 2009-05-07) the use of "-2" was seemingly copy/pasted from parse_long_opt(), which was the function immediately above the parse_nodash_opt() function added in that commit. Since we only care about whether the return value here is non-zero let's use the more generic PARSE_OPT_ERROR. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-10A few hotfixesJunio C Hamano1-7/+20
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-10Merge branch 'jk/ssh-signing-fix'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'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'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'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)Yi-Jyun Pan1-93/+97
Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com>
2021-11-10t/lib-gpg: avoid broken versions of ssh-keygenJeff 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-10receive-pack: ignore SIGPIPE while reporting status to clientRobin Jarry1-0/+2
Before running the post-receive hook, status info is reported back to the client. If a remote client exits before or during the status report, receive-pack is killed by SIGPIPE and post-receive is never executed. The post-receive hook is often used to send email notifications (see contrib/hooks/post-receive-email), update bug trackers, start automatic builds, etc. Not executing it after an interrupted yet "successful" push can lead to inconsistencies. Ignore SIGPIPE before reporting status to the client to increase the chances of post-receive running if pre-receive was successful. This does not guarantee 100% consistency but it should resist early disconnection by the client. Signed-off-by: Robin Jarry <robin@jarry.cc> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-10l10n: fr: v2.34.0 rnd 3Jean-Noël Avila1-93/+97
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
2021-11-10maintenance: disable cron on macOSDerrick 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 3Emir Sarı1-93/+97
Signed-off-by: Emir Sarı <bitigchi@me.com>
2021-11-10simple-ipc: work around issues with Cygwin's Unix socket emulationJohannes 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 3Fangyi Zhou1-94/+98
Signed-off-by: Fangyi Zhou <me@fangyi.io>
2021-11-10Merge branch 'master' of github.com:alshopov/git-poJiang 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)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/gitJiang 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-rc2v2.34.0-rc2Junio C Hamano2-2/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-09Merge branch 'ab/parse-options-cleanup'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'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-09git-jump: pass "merge" arguments to ls-filesJeff King2-1/+4
We currently throw away any arguments given to "git jump merge". We should instead pass them along to ls-files, since they're likely to be pathspecs. This matches the behavior of "git jump diff", etc. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-09parse-options.[ch]: revert use of "enum" for parse_options()Æ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-09doc: use only hyphens as word separators in placeholdersJean-Noël Avila14-76/+76
According to CodingGuidelines, multi-word placeholders should use hyphens as word separators. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> Reviewed-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-09init doc: --shared=0xxx does not give umask but perm bitsJunio C Hamano1-5/+6
The description that 0640 makes sure that the group members can read the repository is correct, but calling that octal number a <umask> is wrong. Let's call it <perm>, as the value is used to set the permission bits. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-09doc: express grammar placeholders between angle bracketsJean-Noël Avila12-41/+41
This discerns user inputs from verbatim options in the synopsis. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-09doc: git-init: clarify file modes in octal.Jean-Noël Avila1-7/+9
The previous explanation was mixing the format with the identity of the field. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>