aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-11-22dir: revert "dir: select directories correctly"Derrick Stolee
This reverts commit f6526728f950cacfd5b5e42bcc65f2c47f3da654. The change in f652672 (dir: select directories correctly, 2021-09-24) caused a regression in directory-based matches with non-cone-mode patterns, especially for .gitignore patterns. A test is included to prevent this regression in the future. The commit ed495847 (dir: fix pattern matching on dirs, 2021-09-24) was reverted in 5ceb663 (dir: fix directory-matching bug, 2021-11-02) for similar reasons. Neither commit changed tests, and tests added later in the series continue to pass when these commits are reverted. Reported-by: Danial Alihosseini <danial.alihosseini@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-22Doc: no midx and partial clone relationJonathan Tan
The multi-pack index treats promisor packfiles (that is, packfiles that have an accompanying .promisor file) the same as other packfiles. Remove a section in the documentation that seems to indicate otherwise. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-22refs: drop force_create argument of create_reflog APIHan-Wen Nienhuys
There is only one caller, builtin/checkout.c, and it hardcodes force_create=1. This argument was introduced in abd0cd3a301 (refs: new public ref function: safe_create_reflog, 2015-07-21), which promised to immediately use it in a follow-on commit, but that never happened. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-210th batch for early fixesJunio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-21Merge branch 'ab/update-submitting-patches'Junio C Hamano
Doc fix. * ab/update-submitting-patches: SubmittingPatches: fix Asciidoc syntax in "GitHub CI" section
2021-11-21Merge branch 'ev/pull-already-up-to-date-is-noop'Junio C Hamano
"git pull" with any strategy when the other side is behind us should succeed as it is a no-op, but doesn't. * ev/pull-already-up-to-date-is-noop: pull: should be noop when already-up-to-date
2021-11-21Merge branch 'hm/paint-hits-in-log-grep'Junio C Hamano
"git grep" looking in a blob that has non-UTF8 payload was completely broken when linked with certain versions of PCREv2 library in the latest release. * hm/paint-hits-in-log-grep: Revert "grep/pcre2: fix an edge case concerning ascii patterns and UTF-8 data"
2021-11-20test-lib: introduce required prereq for test runsFabian Stelzer
In certain environments or for specific test scenarios we might expect a specific prerequisite check to succeed. Therefore we would like to abort running our tests if this is not the case. To remedy this we add the environment variable GIT_TEST_REQUIRE_PREREQ which can be set to a space separated list of prereqs. If one of these prereq tests fail then the whole test run will abort. Signed-off-by: Fabian Stelzer <fs@gigacodes.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-20test-lib: show missing prereq summaryFabian Stelzer
When running the full test suite many tests can be skipped because of missing prerequisites. It not easy right now to get an overview of which ones are missing. When switching to a new machine or environment some libraries and tools might be missing or maybe a dependency broke completely. In this case the tests would indicate nothing since all dependant tests are simply skipped. This could hide broken behaviour or missing features in the build. Therefore this patch summarizes the missing prereqs at the end of the test run making it easier to spot such cases. - Add failed prereqs to the test results. - Aggregate and then show them with the totals. Signed-off-by: Fabian Stelzer <fs@gigacodes.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-19ci(check-whitespace): update stale file top commentsHans Krentel (hakre)
Earlier a066a90d (ci(check-whitespace): restrict to the intended commits, 2021-07-14) changed the check-whitespace task to stop using a shallow clone, and cc003621 (ci(check-whitespace): stop requiring a read/write token, 2021-07-14) changed the way how the errors the task discovered is signaled back to the user. They however forgot to update the comment that outlines what is done in the task. Correct them. Signed-off-by: Hans Krentel (hakre) <hanskrentel@yahoo.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-19fetch-pack: ignore SIGPIPE when writing to index-packJeff King
When fetching, we send the incoming pack to index-pack (or unpack-objects) via the sideband demuxer. If index-pack hits an error (e.g., because an object fails fsck), then it will die immediately. This may cause us to get SIGPIPE on the fetch, as we're still trying to write pack contents from the sideband demuxer (which is typically a thread, and thus takes down the whole fetch process). You can see this in action with: ./t5702-protocol-v2.sh --stress --run=59 which ends with (wrapped for readability): test_must_fail: died by signal 13: git -c protocol.version=2 \ -c transfer.fsckobjects=1 -c fetch.uriprotocols=http,https \ clone http://127.0.0.1:5708/smart/http_parent http_child not ok 59 - packfile-uri with transfer.fsckobjects fails on bad object This is mostly cosmetic. The actual error of interest (in this case, the object that failed the fsck check) comes from index-pack straight to stderr, so the user still sees it. They _might_ even see fetch-pack complaining about index-pack failing, because the main thread is racing with the sideband-demuxer. But they'll definitely see the signal death in the exit code, which is what the test is complaining about. We can make this more predictable by just ignoring SIGPIPE. The sideband demuxer uses write_or_die(), so it will notice and stop (gracefully, because we hook die_routine() to exit just the thread). And during this section we're not writing anywhere else where we'd be concerned about SIGPIPE preventing us from wasting effort writing to nowhere. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-19refs: work around gcc-11 warning with REF_HAVE_NEWJeff King
Using gcc-11 (or 12) to compile refs.o with -O3 results in: In file included from hashmap.h:4, from cache.h:6, from refs.c:5: In function ‘oidcpy’, inlined from ‘ref_transaction_add_update’ at refs.c:1065:3, inlined from ‘ref_transaction_update’ at refs.c:1094:2, inlined from ‘ref_transaction_verify’ at refs.c:1132:9: hash.h:262:9: warning: argument 2 null where non-null expected [-Wnonnull] 262 | memcpy(dst->hash, src->hash, GIT_MAX_RAWSZ); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from git-compat-util.h:177, from cache.h:4, from refs.c:5: refs.c: In function ‘ref_transaction_verify’: /usr/include/string.h:43:14: note: in a call to function ‘memcpy’ declared ‘nonnull’ 43 | extern void *memcpy (void *__restrict __dest, const void *__restrict __src, | ^~~~~~ That call to memcpy() is in a conditional block that requires REF_HAVE_NEW to be set. But in ref_transaction_update(), we make sure it isn't set coming in: if (flags & ~REF_TRANSACTION_UPDATE_ALLOWED_FLAGS) BUG("illegal flags 0x%x passed to ref_transaction_update()", flags); and then only set it if the variable isn't NULL: flags |= (new_oid ? REF_HAVE_NEW : 0) | (old_oid ? REF_HAVE_OLD : 0); So it should be impossible to reach that memcpy() with a NULL oid. But for whatever reason, gcc doesn't accept that hitting the BUG() means we won't go any further, even though it's marked with the noreturn attribute. And the conditional is correct; ALLOWED_FLAGS doesn't contain HAVE_NEW or HAVE_OLD, and you can even simplify it to check for those flags explicitly and the compiler still complains. We can work around this by just clearing the disallowed flags explicitly. This should be a noop because of the BUG() check, but it makes the compiler happy. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-19submodule: absorb git dir instead of dying on deinitMugdha Pattnaik
Currently, running 'git submodule deinit' on repos where the submodule's '.git' is a directory, aborts with a message that is not exactly user friendly. Let's change this to instead warn the user that the .git/ directory has been absorbed into the superproject. The rest of the deinit function can operate as it already does with new-style submodules. In one test, we used to require "git submodule deinit" to fail even with the "--force" option when the submodule's .git/ directory is not absorbed. Adjust it to expect the operation to pass. Suggested-by: Atharva Raykar <raykar.ath@gmail.com> Signed-off-by: Mugdha Pattnaik <mugdhapattnaik@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-19pull: don't say that merge is "the default strategy"Alex Henrie
Git no longer has a default strategy for reconciling divergent branches, because there's no way for Git to know which strategy is appropriate in any particular situation. The initially proposed version in [*], that eventually became 031e2f7a (pull: abort by default when fast-forwarding is not possible, 2021-07-22), dropped this phrase from the message, but it was left in the final version by accident. * https://lore.kernel.org/git/20210627000855.530985-1-alexhenrie24@gmail.com/ Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-19Revert "grep/pcre2: fix an edge case concerning ascii patterns and UTF-8 data"Junio C Hamano
This reverts commit ae39ba431ab861548eb60b4bd2e1d8b8813db76f, as it breaks "grep" when looking for a string in non UTF-8 haystack, when linked with certain versions of PCREv2 library. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-19ssh signing: make sign/amend test more resilientFabian Stelzer
The test `amending already signed commit` is using git checkout to select a specific commit to amend. In case an earlier test fails and leaves behind a dirty index/worktree this test would fail as well. Using `checkout -f` will avoid interference by most other tests. Signed-off-by: Fabian Stelzer <fs@gigacodes.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-19ssh signing: support non ssh-* keytypesFabian Stelzer
The user.signingKey config for ssh signing supports either a path to a file containing the key or for the sake of convenience a literal string with the ssh public key. To differentiate between those two cases we check if the first few characters contain "ssh-" which is unlikely to be the start of a path. ssh supports other key types which are not prefixed with "ssh-" and will currently be treated as a file path and therefore fail to load. To remedy this we move the prefix check into its own function and introduce the prefix `key::` for literal ssh keys. This way we don't need to add new key types when they become available. The existing `ssh-` prefix is retained for compatibility with current user configs but removed from the official documentation to discourage its use. Signed-off-by: Fabian Stelzer <fs@gigacodes.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-18trace2: disable tr2_dst before warning on write errorsJosh Steadmon
If writing a trace2 message fails, we optionally warn the user of this fact. However, in 0ee10fd (usage: add trace2 entry upon warning(), 2020-11-23), we added a trace entry to the warning() function. This means that we can enter an infinite loop of failing trace2 writes and warnings. Fix this by disabling the failing trace2 destination before issuing the warning. Additionally, trace2 sets a default SIGPIPE handler (tr2main_signal_handler) when it is initialized. This handler generates its own trace2 messages when a signal is received. If a trace2 write fails due to a broken pipe, this handler will run and then cause another failed write. Fix this by temporarily ignoring SIGPIPE while writing trace2 messages. This is safe because the write will still fail, and we will disable the failing destination. Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-18remote: die if branch is not found in repositoryGlen Choo
In a subsequent commit, we would like external-facing functions to be able to accept "struct repository" and "struct branch" as a pair. This is useful for functions like pushremote_for_branch(), which need to take values from the remote_state and branch, even if branch == NULL. However, a caller may supply an unrelated repository and branch, which is not supported behavior. To prevent misuse, add a die_on_missing_branch() helper function that dies if a given branch is not from a given repository. Speed up the existence check by replacing the branches list with a branches_hash hashmap. Like read_config(), die_on_missing_branch() is only called from non-static functions; static functions are less prone to misuse because they have strong conventions for keeping remote_state and branch in sync. Signed-off-by: Glen Choo <chooglen@google.com> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-18remote: remove the_repository->remote_state from static methodsGlen Choo
Replace all remaining references of the_repository->remote_state in static functions with a struct remote_state parameter. To do so, move read_config() calls to non-static functions and create a family of static functions, "remotes_*", that behave like "repo_*", but accept struct remote_state instead of struct repository. In the case where a static function calls a non-static function, replace the non-static function with its "remotes_*" equivalent. Signed-off-by: Glen Choo <chooglen@google.com> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-18remote: use remote_state parameter internallyGlen Choo
Without changing external-facing functions, replace the_repository->remote_state internally by adding a struct remote_state parameter. As a result, external-facing functions are still tied to the_repository, but most static functions no longer reference the_repository->remote_state. The exceptions are those that are used in a way that depends on external-facing functions e.g. the callbacks to remote_get_1(). Signed-off-by: Glen Choo <chooglen@google.com> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-18remote: move static variables into per-repository structGlen Choo
remote.c does not works with non-the_repository because it stores its state as static variables. To support non-the_repository, we can use a per-repository struct for the remotes subsystem. Prepare for this change by defining a struct remote_state that holds the remotes subsystem state and move the static variables of remote.c into the_repository->remote_state. This introduces no behavioral or API changes. Signed-off-by: Glen Choo <chooglen@google.com> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-18t5516: add test case for pushing remote refspecsGlen Choo
"git push remote-name" (that is, with no refspec given on the command line) should push the refspecs in remote.remote-name.push. There is no test case that checks this behavior in detached HEAD, so add one. Signed-off-by: Glen Choo <chooglen@google.com> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-18xdiff: simplify comparisonPhillip Wood
Now that the histogram algorithm calls xdl_classify_record() it is no longer necessary to use xdl_recmatch() to compare lines, it is sufficient just to compare the hash values. This has a negligible effect on performance. Test HEAD~1 HEAD ----------------------------------------------------------------------------- 4000.1: log -3000 (baseline) 0.19(0.12+0.07) 0.18(0.14+0.04) -5.3% 4000.2: log --raw -3000 (tree-only) 0.98(0.81+0.16) 0.98(0.79+0.18) +0.0% 4000.3: log -p -3000 (Myers) 4.81(4.23+0.56) 4.80(4.26+0.53) -0.2% 4000.4: log -p -3000 --histogram 5.83(5.11+0.70) 5.82(5.15+0.65) -0.2% 4000.5: log -p -3000 --patience 5.31(4.61+0.69) 5.30(4.54+0.75) -0.2% Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-18xdiff: avoid unnecessary memory allocationsPhillip Wood
rindex and ha are only used by xdl_cleanup_records() which is not called by the histogram or patience algorithms. The perf test results show a small reduction in run time but that is probably within the noise. Test HEAD^ HEAD ----------------------------------------------------------------------------- 4000.1: log -3000 (baseline) 0.19(0.17+0.02) 0.19(0.12+0.07) +0.0% 4000.2: log --raw -3000 (tree-only) 0.98(0.78+0.20) 0.98(0.81+0.16) +0.0% 4000.3: log -p -3000 (Myers) 4.81(4.15+0.64) 4.81(4.23+0.56) +0.0% 4000.4: log -p -3000 --histogram 5.87(5.19+0.66) 5.83(5.11+0.70) -0.7% 4000.5: log -p -3000 --patience 5.35(4.60+0.73) 5.31(4.61+0.69) -0.7% Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-18diff histogram: intern stringsPhillip Wood
Histogram is the only diff algorithm not to call xdl_classify_record(). xdl_classify_record() ensures that the hash values of two strings that are not equal differ which means that it is not necessary to use xdl_recmatch() when comparing lines, all that is necessary is to compare the hash values. This gives a 7% reduction in the runtime of "git log --patch" when using the histogram diff algorithm. Test HEAD^ HEAD ----------------------------------------------------------------------------- 4000.1: log -3000 (baseline) 0.18(0.14+0.04) 0.19(0.17+0.02) +5.6% 4000.2: log --raw -3000 (tree-only) 0.99(0.77+0.21) 0.98(0.78+0.20) -1.0% 4000.3: log -p -3000 (Myers) 4.84(4.31+0.51) 4.81(4.15+0.64) -0.6% 4000.4: log -p -3000 --histogram 6.34(5.86+0.46) 5.87(5.19+0.66) -7.4% 4000.5: log -p -3000 --patience 5.39(4.60+0.76) 5.35(4.60+0.73) -0.7% Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-18pull: should be noop when already-up-to-dateErwin Villejo
The already-up-to-date pull bug was fixed for --ff-only but it did not include the case where --ff or --ff-only are not specified. This updates the --ff-only fix to include the case where --ff or --ff-only are not specified in command line flags or config. Signed-off-by: Erwin Villejo <erwin.villejo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-18t5319: corrupt more bytes of the midx checksumJeff King
One of the tests in t5319 corrupts the checksum of the midx file by writing a single 0xff over the final byte, and then confirms that we detect the problem. This usually works fine, but would break if the actual checksum ended with that same byte already. It seems like this should happen in 1 out of 256 test runs, but it turns out to be less often in practice. The contents of the midx are mostly deterministic because it's based on the objects, and we remove most sources of randomness by setting GIT_COMMITTER_DATE, etc. However, there's still some randomness: some objects are duplicated between packs, and the midx must decide which to use, which can be based on timing. So very occasionally we can end up with a real 0xff byte, and the test fails. The most robust fix would be to read out the final byte and then change it to something else (e.g., adding 1 mod 256). But that's awkward to do in shell. Let's just blindly corrupt 10 bytes instead of 1, which reduces our chances of an accidental noop to 1 in 2^80. Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-18checkout: fix "branch info" memory leaksÆvar Arnfjörð Bjarmason
The "checkout" command is one of the main sources of leaks in the test suite, let's fix the common ones by not leaking from the "struct branch_info". Doing this is rather straightforward, albeit verbose, we need to xstrdup() constant strings going into the struct, and free() the ones we clobber as we go along. This also means that we can delete previous partial leak fixes in this area, i.e. the "path_to_free" accounting added by 96ec7b1e708 (Convert resolve_ref+xstrdup to new resolve_refdup function, 2011-12-13). There was some discussion about whether "we should retain the "const char *" here and cast at free() time, or have it be a "char *". Since this is not a public API with any sort of API boundary let's use "char *", as is already being done for the "refname" member of the same struct. The tests to mark as passing were found with: rm .prove; GIT_SKIP_TESTS=t0027 prove -j8 --state=save t[0-9]*.sh :: --immediate # apply & compile this change prove -j8 --state=failed :: --immediate I.e. the ones that were newly passing when the --state=failed command was run. I left out "t3040-subprojects-basic.sh" and "t4131-apply-fake-ancestor.sh" to to optimization-level related differences similar to the ones noted in[1], except that these would be something the current 'linux-leaks' job would run into. 1. https://lore.kernel.org/git/cover-v3-0.6-00000000000-20211022T175227Z-avarab@gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-18mergesort: avoid left shift overflowRené Scharfe
Use size_t to match n when building the bitmask for checking whether a rank is occupied, instead of the default signed int. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-18midx: fix a formatting issue in "multi-pack-index.txt"Teng Long
There is a formatting issue in "multi-pack-index.html", corresponding to the nesting bulleted list of a wrong usage in "multi-pack-index.txt" and this commit fix the problem. In ASCIIDOC, it doesn't treat an indented character as the beginning of a sub-list. If we want to write a nested bulleted list, we could just use ASTERISK without any DASH like: " * Level 1 list item ** Level 2 list item *** Level 3 list item ** Level 2 list item * Level 1 list item ** Level 2 list item * Level 1 list item " The DASH can be used for bulleted list too, But the DASH is suggested only to be used as the marker for the first level because the DASH doesn’t work well or a best practice for nested lists, like (dash is as level 2 below): " * Level 1 list item - Level 2 list item * Level 1 list item " ASTERISK is recommanded to use because it works intuitively and clearly ("marker length = nesting level") in nested lists, but the DASH can't. However, when you want to write a non-nested bulleted lists, DASH works too, like: " - Level 1 list item - Level 1 list item - Level 1 list item " Reviewed-by: Taylor Blau <me@ttaylorr.com> Reviewed-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Teng Long <dyroneteng@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-11-14Git 2.34v2.34.0Junio C Hamano
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-poJunio C Hamano
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 3Arusekk
Signed-off-by: Arusekk <arek_koz@o2.pl>
2021-11-14l10n: it: fix typos found by git-po-helperJiang Xin
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2021-11-13SubmittingPatches: fix Asciidoc syntax in "GitHub CI" sectionPhilippe Blain
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 Xin
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 Mas
Signed-off-by: Jordi Mas <jmas@softcatala.org>
2021-11-13Merge branch 'po-id' of github.com:bagasme/git-poJiang Xin
* '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 Sanjaya
- 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 Xin
* '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 Hamano
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 Hamano
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 Hamano
Regression fix. * ps/connectivity-optim: Revert "connected: do not sort input revisions"
2021-11-12l10n: bg.po: Updated Bulgarian translation (5211t)Alexander Shopov
Signed-off-by: Alexander Shopov <ash@kambanaria.org>
2021-11-12l10n: de.po: Update German translation for Git v2.34.0Matthias Rüster
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 Steadmon
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 Wan
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 Krefting
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2021-11-11object-file: free(*contents) only in read_loose_object() callerÆvar Arnfjörð Bjarmason
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>