summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-04-29Merge branch 'fr_v2.45.0' of github.com:jnavila/gitJiang Xin1-239/+442
* 'fr_v2.45.0' of github.com:jnavila/git: l10n: fr: v2.45.0
2024-04-29l10n: tr: Update Turkish translationsEmir SARI1-250/+411
Signed-off-by: Emir SARI <emir_sari@icloud.com>
2024-04-28Merge branch 'l10n/zh-TW/240428' of github.com:l10n-tw/git-poJiang Xin1-331/+579
* 'l10n/zh-TW/240428' of github.com:l10n-tw/git-po: l10n: zh-TW: Git 2.45
2024-04-28Merge branch 'tl/zh_CN_2.45.0_rnd' of github.com:dyrone/gitJiang Xin1-294/+504
* 'tl/zh_CN_2.45.0_rnd' of github.com:dyrone/git: l10n: zh_CN: for git 2.45 rounds
2024-04-28l10n: zh_CN: for git 2.45 roundsTeng Long1-294/+504
Signed-off-by: Teng Long <dyroneteng@gmail.com>
2024-04-28l10n: zh-TW: Git 2.45Yi-Jyun Pan1-331/+579
Co-Authored-By: Lumynous <lumynou5.tw@gmail.com> Co-Authored-By: Kisaragi Hiu <mail@kisaragi-hiu.com> Signed-off-by: Yi-Jyun Pan <pan93412@gmail.com>
2024-04-28Merge branch 'update-teams' of https://github.com/Nekosha/git-poJiang Xin1-3/+4
* 'update-teams' of https://github.com/Nekosha/git-po: l10n: Update Vietnamese team contact
2024-04-28l10n: vi: Updated translation for 2.45Vũ Tiến Hưng1-4522/+5227
Signed-off-by: Vũ Tiến Hưng <newcomerminecraft@gmail.com>
2024-04-28l10n: TEAMS: retire l10n teams no update in 1 yearJiang Xin1-8/+8
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2024-04-28Merge branch 'l10n/uk/2.45-uk-update'Jiang Xin1-245/+418
* '2.45-uk-update' of github.com:arkid15r/git-ukrainian-l10n: l10n: uk: v2.45 update
2024-04-28Merge branch 'l10n-de-2.45' of github.com:ralfth/gitJiang Xin1-250/+420
* 'l10n-de-2.45' of github.com:ralfth/git: l10n: Update German translation
2024-04-28Merge branch 'po-id' of github.com:bagasme/git-poJiang Xin1-302/+510
* 'po-id' of github.com:bagasme/git-po: l10n: po-id for 2.45
2024-04-27l10n: uk: v2.45 updateArkadii Yakovets1-245/+418
Co-authored-by: Kate Golovanova <kate@kgthreads.com> Signed-off-by: Arkadii Yakovets <ark@cho.red> Signed-off-by: Kate Golovanova <kate@kgthreads.com>
2024-04-27l10n: sv.po: Update Swedish translationPeter Krefting1-391/+550
Also fix some inconsistencies, and fix issue reported by Anders Jonsson <anders.jonsson@norsjovallen.se>. Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2024-04-26vimdiff: make script and tests work with zshbrian m. carlson1-2/+1
When we process the $LAYOUT variable through sed, the result will end with the character "#". We then split it at the shell using IFS so that we can process it a character at a time. POSIX specifies that only "IFS white space shall be ignored at the beginning and end of the input". The hash mark is not a white space character, so it is not ignored at the beginning and end of the input. POSIX then specifies that "[e]ach occurrence in the input of an IFS character that is not IFS white space, along with any adjacent IFS white space, shall delimit a field, as described previously." Thus, the final hash mark delimits a field, and the final field is the empty string. zsh implements this behavior strictly in compliance with POSIX (and differently from most other shells), such that we end up with a trailing empty field. We don't want this empty field and processing it in the normal way causes us to fail to parse properly and fail the tests with "ERROR" entries, so let's just ignore it instead. This is the behavior of bash and dash anyway and what was clearly intended, so this is a reasonable thing to do. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-26t4046: avoid continue in &&-chain for zshbrian m. carlson1-7/+9
zsh has a bug in which the keyword "continue" within an &&-chain is not effective and the code following it is executed nonetheless. Fortunately, this bug has been fixed upstream in 12e5db145 ("51608: Don't execute commands after "continue &&"", 2023-03-29). However, zsh releases very infrequently, so it is not present in a stable release yet. That, combined with the fact that almost all zsh users get their shell from their OS vendor, means that it will likely be a long time before this problem is fixed for most users. We have other workarounds in place for FreeBSD ash and dash, so it shouldn't be too difficult to add one here, either. Replace the existing code with a test and if-block, which comes only at the cost of an additional indentation, and leaves the code a little more idiomatic anyway. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-26l10n: Update German translationRalf Thielow1-250/+420
Reviewed-by: Matthias Rüster <matthias.ruester@gmail.com> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
2024-04-26l10n: po-id for 2.45Bagas Sanjaya1-302/+510
Translate following new components: * refs/reftable-backend.c Update following components: * branch.c * builtin/column.c * builtin/config.c * builtin/for-each-ref.c * builtin/pack-refs.c * revision.c Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
2024-04-25doc: clarify practices for submitting updated patch versionsJustin Tobler1-4/+6
The `SubmittingPatches` documentation briefly mentions that related patches should be grouped together in their own e-mail thread. Expand on this to explicitly state that updated versions of a patch series should also follow this. Also provide add a link to existing documentation from `MyFirstContribution` that provides detailed instructions on how to do this via `git-send-email(1)`. Signed-off-by: Justin Tobler <jltobler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-25Merge branch 'rj/add-i-leak-fix'Junio C Hamano14-4/+23
Leakfix. * rj/add-i-leak-fix: add: plug a leak on interactive_add add-patch: plug a leak handling the '/' command add-interactive: plug a leak in get_untracked_files apply: plug a leak in apply_data
2024-04-25Merge branch 'rs/vsnprintf-failure-is-not-a-bug'Junio C Hamano3-4/+5
Demote a BUG() to an die() when the failure from vsnprintf() may not be due to a programmer error. * rs/vsnprintf-failure-is-not-a-bug: don't report vsnprintf(3) error as bug
2024-04-25completion: add docs on how to add subcommand completionsRoland Hieber1-0/+7
Signed-off-by: Roland Hieber <rhi@pengutronix.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-25completion: improve docs for using __git_completeRoland Hieber1-3/+10
It took me more than a few tries and a good lecture of __git_main to understand that the two paragraphs really only refer to adding completion functions for executables that are not called through git's subcommand magic. Improve the docs and be more specific. Signed-off-by: Roland Hieber <rhi@pengutronix.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-25completion: add 'symbolic-ref'Roland Hieber2-0/+34
Even 'symbolic-ref' is only completed when GIT_COMPLETION_SHOW_ALL_COMMANDS=1 is set, it currently defaults to completing file names, which is not very helpful. Add a simple completion function which completes options and refs. Signed-off-by: Roland Hieber <rhi@pengutronix.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-24fuzz: link fuzz programs with `make all` on LinuxJosh Steadmon3-22/+32
Since 5e47215080 (fuzz: add basic fuzz testing target., 2018-10-12), we have compiled object files for the fuzz tests as part of the default 'make all' target. This helps prevent bit-rot in lesser-used parts of the codebase, by making sure that incompatible changes are caught at build time. However, since we never linked the fuzzer executables, this did not protect us from link-time errors. As of 8b9a42bf48 (fuzz: fix fuzz test build rules, 2024-01-19), it's now possible to link the fuzzer executables without using a fuzzing engine and a variety of compiler-specific (and compiler-version-specific) flags, at least on Linux. So let's add a platform-specific option in config.mak.uname to link the executables as part of the default `make all` target. Since linking the fuzzer executables without a fuzzing engine does not require a C++ compiler, we can change the FUZZ_PROGRAMS build rule to use $(CC) by default. This avoids compiler mis-match issues when overriding $(CC) but not $(CXX). When we *do* want to actually link with a fuzzing engine, we can set $(FUZZ_CXX). The build instructions in the CI fuzz-smoke-test job and in the Makefile comment have been updated accordingly. While we're at it, we can consolidate some of the fuzzer build instructions into one location in the Makefile. Suggested-by: Junio C Hamano <gitster@pobox.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-24maintenance: running maintenance should not stop on errorsJohannes Schindelin2-6/+7
In https://github.com/microsoft/git/issues/623, it was reported that maintenance stops on a missing repository, omitting the remaining repositories that were scheduled for maintenance. This is undesirable, as it should be a best effort type of operation. It should still fail due to the missing repository, of course, but not leave the non-missing repositories in unmaintained shapes. Let's use `for-each-repo`'s shiny new `--keep-going` option that we just introduced for that very purpose. This change will be picked up when running `git maintenance start`, which is run implicitly by `scalar reconfigure`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-24for-each-repo: optionally keep going on an errorJohannes Schindelin3-2/+36
In https://github.com/microsoft/git/issues/623, it was reported that the regularly scheduled maintenance stops if one repo in the middle of the list was found to be missing. This is undesirable, and points out a gap in the design of `git for-each-repo`: We need a mode where that command does not stop on an error, but continues to try running the specified command with the other repositories. Imitating the `--keep-going` option of GNU make, this commit teaches `for-each-repo` the same trick: to continue with the operation on all the remaining repositories in case there was a problem with one repository, still setting the exit code to indicate an error occurred. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-24Documentation/RelNotes/2.45.0.txt: fix typoTaylor Blau1-1/+1
Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-23Git 2.45-rc1v2.45.0-rc1Junio C Hamano2-1/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-23Merge branch 'ps/run-auto-maintenance-in-receive-pack'Junio C Hamano4-17/+30
The "receive-pack" program (which responds to "git push") was not converted to run "git maintenance --auto" when other codepaths that used to run "git gc --auto" were updated, which has been corrected. * ps/run-auto-maintenance-in-receive-pack: builtin/receive-pack: convert to use git-maintenance(1) run-command: introduce function to prepare auto-maintenance process
2024-04-23Merge branch 'pk/bisect-use-show'Junio C Hamano1-15/+24
When "git bisect" reports the commit it determined to be the culprit, we used to show it in a format that does not honor common UI tweaks, like log.date and log.decorate. The code has been taught to use "git show" to follow more customizations. * pk/bisect-use-show: bisect: report the found commit with "show"
2024-04-23A bit more topics before -rc1Junio C Hamano1-0/+33
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-23Merge branch 'rs/apply-reject-long-name'Junio C Hamano1-16/+17
The filename used for rejected hunks "git apply --reject" creates was limited to PATH_MAX, which has been lifted. * rs/apply-reject-long-name: apply: avoid using fixed-size buffer in write_out_one_reject()
2024-04-23Merge branch 'mr/rerere-crash-fix'Junio C Hamano2-0/+68
When .git/rr-cache/ rerere database gets corrupted or rerere is fed to work on a file with conflicted hunks resolved incompletely, the rerere machinery got confused and segfaulted, which has been corrected. * mr/rerere-crash-fix: rerere: fix crashes due to unmatched opening conflict markers
2024-04-23Merge branch 'rs/imap-send-simplify-cmd-issuing-codepath'Junio C Hamano1-23/+12
Code simplification. * rs/imap-send-simplify-cmd-issuing-codepath: imap-send: increase command size limit
2024-04-23Merge branch 'xx/rfc2822-date-format-in-doc'Junio C Hamano2-2/+2
Docfix. * xx/rfc2822-date-format-in-doc: Documentation: fix typos describing date format
2024-04-23Merge branch 'ps/missing-btmp-fix'Junio C Hamano3-23/+42
GIt 2.44 introduced a regression that makes the updated code to barf in repositories with multi-pack index written by older versions of Git, which has been corrected. * ps/missing-btmp-fix: pack-bitmap: gracefully handle missing BTMP chunks
2024-04-23Merge branch 'la/format-trailer-info'Junio C Hamano2-62/+32
The code to format trailers have been cleaned up. * la/format-trailer-info: trailer: finish formatting unification trailer: begin formatting unification format_trailer_info(): append newline for non-trailer lines format_trailer_info(): drop redundant unfold_value() format_trailer_info(): use trailer_item objects
2024-04-23Merge branch 'dd/t9604-use-posix-timezones'Junio C Hamano1-6/+23
The cvsimport tests required that the platform understands traditional timezone notations like CST6CDT, which has been updated to work on those systems as long as they understand POSIX notation with explicit tz transition dates. * dd/t9604-use-posix-timezones: t9604: Fix test for musl libc and new Debian
2024-04-23Merge branch 'rj/launch-editor-error-message'Junio C Hamano1-4/+3
Git writes a "waiting for your editor" message on an incomplete line after launching an editor, and then append another error message on the same line if the editor errors out. It now clears the "waiting for..." line before giving the error message. * rj/launch-editor-error-message: launch_editor: waiting message on error
2024-04-23Merge branch 'yb/replay-doc-linkfix'Junio C Hamano1-1/+1
Docfix. * yb/replay-doc-linkfix: Documentation: fix linkgit reference
2024-04-23Merge branch 'rs/no-openssl-compilation-fix-on-macos'Junio C Hamano1-0/+1
Build fix. * rs/no-openssl-compilation-fix-on-macos: git-compat-util: fix NO_OPENSSL on current macOS
2024-04-23Merge branch 'ta/fast-import-parse-path-fix'Junio C Hamano3-262/+555
The way "git fast-import" handles paths described in its input has been tightened up and more clearly documented. * ta/fast-import-parse-path-fix: fast-import: make comments more precise fast-import: forbid escaped NUL in paths fast-import: document C-style escapes for paths fast-import: improve documentation for path quoting fast-import: remove dead strbuf fast-import: allow unquoted empty path for root fast-import: directly use strbufs for paths fast-import: tighten path unquoting
2024-04-23Merge branch 'ps/reftable-block-iteration-optim'Junio C Hamano5-178/+229
The code to iterate over reftable blocks has seen some optimization to reduce memory allocation and deallocation. * ps/reftable-block-iteration-optim: reftable/block: avoid copying block iterators on seek reftable/block: reuse `zstream` state on inflation reftable/block: open-code call to `uncompress2()` reftable/block: reuse uncompressed blocks reftable/reader: iterate to next block in place reftable/block: move ownership of block reader into `struct table_iter` reftable/block: introduce `block_reader_release()` reftable/block: better grouping of functions reftable/block: merge `block_iter_seek()` and `block_reader_seek()` reftable/block: rename `block_reader_start()`
2024-04-23format-patch: "--rfc=-(WIP)" appends to produce [PATCH (WIP)]Junio C Hamano3-2/+21
In the previous step, the "--rfc" option of "format-patch" learned to take an optional string value to prepend to the subject prefix, so that --rfc=WIP can give "[WIP PATCH]". There may be cases in which the extra string wants to come after the subject prefix. Extend the mechanism to allow "--rfc=-(WIP)" [*] to signal that the extra string is to be appended instead of getting prepended, resulting in "[PATCH (WIP)]". In the documentation, discourage (ab)using "--rfc=-RFC" to say "[PATCH RFC]" just to be different, when "[RFC PATCH]" is the norm. [Footnote] * The syntax takes inspiration from Perl's open syntax that opens pipes "open fh, '|-', 'cmd'", where the dash signals "the other stuff comes here". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-23format-patch: allow --rfc to optionally take a value, like --rfc=WIPJunio C Hamano3-11/+48
With the "--rfc" option, we can tweak the "[PATCH]" (or whatever string specified with the "--subject-prefix" option, instead of "PATCH") that we prefix the title of the commit with into "[RFC PATCH]", but some projects may want "[rfc PATCH]". Adding a new option, e.g., "--rfc-lowercase", to support such need every time somebody wants to use different strings would lead to insanity of accumulating unbounded number of such options. Allow an optional value specified for the option, so that users can use "--rfc=rfc" (think of "--rfc" without value as a short-hand for "--rfc=RFC") if they wanted to. This can of course be (ab)used to make the prefix "[WIP PATCH]" by passing "--rfc=WIP". Passing an empty string, i.e., "--rfc=", is the same as "--no-rfc" to override an option given earlier on the same command line. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-22add: plug a leak on interactive_addRubén Justo3-3/+9
Plug a leak we have since 5a76aff1a6 (add: convert to use parse_pathspec, 2013-07-14). This leak can be triggered with: $ git add -p anything Fixing this leak allows us to mark as leak-free the following tests: + t3701-add-interactive.sh + t7514-commit-patch.sh Mark them with "TEST_PASSES_SANITIZE_LEAK=true" to notice and fix promply any new leak that may be introduced and triggered by them in the future. Signed-off-by: Rubén Justo <rjusto@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-22add-patch: plug a leak handling the '/' commandRubén Justo1-0/+1
Plug a leak we have since d6cf873340 (built-in add -p: implement the '/' ("search regex") command, 2019-12-13). This leak can be triggered with: $ printf "A\n\nB\n" >file $ git add file && git commit -m file $ printf "AA\n\nBB\n" >file $ printf "s\n/ .\n" >lines $ git add -p <lines Signed-off-by: Rubén Justo <rjusto@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-22add-interactive: plug a leak in get_untracked_filesRubén Justo1-0/+1
Plug a leak we have since ab1e1cccaf (built-in add -i: re-implement `add-untracked` in C, 2019-11-29). This leak can be triggered with: $ echo a | git add -i As a curiosity, we have a somewhat similar function in builtin/stash.c, which correctly frees the memory. Signed-off-by: Rubén Justo <rjusto@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-22apply: plug a leak in apply_dataRubén Justo9-1/+12
We have an execution path in apply_data that leaks the local struct image. Plug it. This leak can be triggered with: $ echo foo >file $ git add file && git commit -m file $ echo bar >file $ git diff file >diff $ sed s/foo/frotz/ <diff >baddiff $ git apply --cached <baddiff Fixing this leak allows us to mark as leak-free the following tests: + t2016-checkout-patch.sh + t4103-apply-binary.sh + t4104-apply-boundary.sh + t4113-apply-ending.sh + t4117-apply-reject.sh + t4123-apply-shrink.sh + t4252-am-options.sh + t4258-am-quoted-cr.sh Mark them with "TEST_PASSES_SANITIZE_LEAK=true" to notice and fix promply any new leak that may be introduced and triggered by them in the future. Signed-off-by: Rubén Justo <rjusto@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>