summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-10-04Merge branch 'tb/weak-sha1-for-tail-sum'Junio C Hamano1-0/+3
Build fix. * tb/weak-sha1-for-tail-sum: hash.h: set NEEDS_CLONE_HELPER_UNSAFE in fallback mode
2024-10-04Merge branch 'ps/reftable-concurrent-writes'Junio C Hamano1-5/+12
Test fix. * ps/reftable-concurrent-writes: t0610: work around flaky test with concurrent writers
2024-10-04Merge branch 'mh/w-unused-fix'Junio C Hamano1-2/+3
Buildfix. * mh/w-unused-fix: utf8.h: squelch unused-parameter warnings with NO_ICONV
2024-10-04Merge branch 'rs/archive-with-attr-pathspec-fix'Junio C Hamano1-1/+2
Message update. * rs/archive-with-attr-pathspec-fix: archive: fix misleading error message
2024-10-04Merge branch 'ak/typofix-2.46-maint'Junio C Hamano5-5/+5
Typofixes. * ak/typofix-2.46-maint: perl: fix a typo mergetool: fix a typo reftable: fix a typo trace2: fix typos
2024-10-04l10n: fr.po: 2.47.0Jean-Noël Avila1-60/+194
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
2024-10-05l10n: zh_CN: updated translation for 2.47Teng Long1-72/+240
Signed-off-by: Teng Long <dyroneteng@gmail.com>
2024-10-04A bit more after 2.47-rc1Junio C Hamano1-0/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-04Merge branch 'ds/read-cache-mempool-leakfix'Junio C Hamano1-0/+1
Leakfix. * ds/read-cache-mempool-leakfix: read-cache: free threaded memory pool
2024-10-04Merge branch 'jc/doc-discarding-stalled-topics'Junio C Hamano1-1/+16
Document that inactive topics are subject to be discarded. * jc/doc-discarding-stalled-topics: howto-maintain-git: discarding inactive topics
2024-10-04Merge branch 'jk/test-lsan-improvements'Junio C Hamano2-36/+8
Usability improvements for running tests in leak-checking mode. * jk/test-lsan-improvements: test-lib: check for leak logs after every test test-lib: show leak-sanitizer logs on --immediate failure test-lib: stop showing old leak logs
2024-10-04t0610: work around flaky test with concurrent writersPatrick Steinhardt1-5/+12
In 6241ce2170 (refs/reftable: reload locked stack when preparing transaction, 2024-09-24) we have introduced a new test that exercises how the reftable backend behaves with many concurrent writers all racing with each other. This test was introduced after a couple of fixes in this context that should make concurrent writes behave gracefully. As it turns out though, Windows systems do not yet handle concurrent writes properly, as we've got two reports for Cygwin and MinGW failing in this newly added test. The root cause of this is how we update the "tables.list" file: when writing a new stack of tables we first write the data into a lockfile and then rename that file into place. But Windows forbids us from doing that rename when the target path is open for reading by another process. And as the test races both readers and writers with each other we are quite likely to hit this edge case. This is not a regression: the logic didn't work before the mentioned commit, and after the commit it performs well on Linux and macOS, and the situation on Windows should have at least improved a bit. But the test shows that we need to put more thought into how to make this work properly there. Work around the issue by disabling the test on Windows for now. While at it, increase the locking timeout to address reported timeouts when using either the address or memory sanitizer, which also tend to significantly extend the runtime of this test. This should be revisited after Git v2.47 is out. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-04fsmonitor OSX: fix hangs for submodulesKoji Nakamaru2-0/+52
fsmonitor_classify_path_absolute() expects state->path_gitdir_watch.buf has no trailing '/' or '.' For a submodule, fsmonitor_run_daemon() sets the value with trailing "/." (as repo_get_git_dir(the_repository) on Darwin returns ".") so that fsmonitor_classify_path_absolute() returns IS_OUTSIDE_CONE. In this case, fsevent_callback() doesn't update cookie_list so that fsmonitor_publish() does nothing and with_lock__mark_cookies_seen() is not invoked. As with_lock__wait_for_cookie() infinitely waits for state->cookies_cond that with_lock__mark_cookies_seen() should unlock, the whole daemon hangs. Remove trailing "/." from state->path_gitdir_watch.buf for submodules and add a corresponding test in t7527-builtin-fsmonitor.sh. The test is disabled for MINGW because hangs treated with this patch occur only for Darwin and there is no simple way to terminate the win32 fsmonitor daemon that hangs. Suggested-by: Johannes Schindelin <johannes.schindelin@gmx.de> Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Koji Nakamaru <koji.nakamaru@gree.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-04reftable/basics: fix segfault when growing `names` array failsPatrick Steinhardt1-2/+4
When growing the `names` array fails we would end up with a `NULL` pointer. This causes two problems: - We would run into a segfault because we try to free names that we have assigned to the array already. - We lose track of the old array and cannot free its contents. Fix this issue by using a temporary variable. Like this we do not clobber the old array that we tried to reallocate, which will remain valid when a call to realloc(3P) fails. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-04l10n: po-id for 2.47Bagas Sanjaya1-77/+246
Update following components: * add-patch.c * apply.c * builtin/check-mailmap.c * builtin/checkout.c * builtin/commit.c * builtin/config.c * builtin/fetch.c * builtin/gc.c * builtin/multi-pack-index.c * builtin/refs.c * builtin/show-refs.c * builtin/sparse-checkout.c * builtin/submodule--helper.c * loose.c * midx-write.c * midx.c * object-file.c * ref-filter.c * refs/file-backend.c * scalar.c * setup.c * git-send-email.perl Translate following new components: * t/unit-tests/unit-tests.c Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
2024-10-03diff: store graph prefix buf in git_graph structJeff King1-6/+12
The diffopt output_prefix interface makes it the callback's job to handle ownership of the memory it returns, keeping it valid while callers are using it and then eventually freeing it when we are done diffing. In diff_output_prefix_callback() we handle this with a static strbuf, effectively "leaking" it when the diff is done (but not triggering any leak detectors because it's technically still reachable). This has not been a big problem in practice, but it is a problem for libification: two diffs running in the same process could stomp on each other's prefix buffers. Since we only need the strbuf when we are formatting graph padding, we can give ownership of the strbuf to the git_graph struct, letting us free it when that struct is no longer in use. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-03diff: return line_prefix directly when possibleJeff King1-0/+3
We may point our output_prefix callback to diff_output_prefix_callback() in any of these cases: 1. we have a user-provided line_prefix 2. we have a graph prefix to show 3. both (1) and (2) The function combines the available elements into a strbuf and returns its pointer. In the case that we just have the line_prefix, though, there is no need for the strbuf. We can return the string directly. This is a minor optimization by itself, but also will allow us to clean up some memory ownership issues on top. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-03diff: return const char from output_prefix callbackJeff King6-19/+11
The diff_options structure has an output_prefix callback for returning a prefix string, but it does so by returning a pointer to a strbuf. This makes the interface awkward. There's no reason the callback should need to use a strbuf, and it creates questions about whether the ownership of the resulting buffer should be transferred to the caller (it should not be, but a recent attempt to clean up this code led to a double-free in some cases). The one advantage we get is that the strbuf contains a ptr/len pair, so we could in theory have a prefix with embedded NULs. But we can observe that none of the existing callbacks would ever produce such a NUL (they are usually just indentation or graph symbols, and even the "--line-prefix" option takes a NUL-terminated string). And anyway, only one caller (the one in log_tree_diff_flush) actually looks at the strbuf length. In every other case we use a helper function which discards the length and just returns the NUL-terminated string. So let's just have the callback return a "const char *" pointer. It's up to the callbacks themselves if they want to use a strbuf under the hood. And now the caller in log_tree_diff_flush() can just use the helper function along with everybody else. That lets us even simplify out the function pointer check, since the helper returns an empty string (technically this does mean we'll sometimes issue an empty fputs() call, but I don't think this code path is hot enough to care about that). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-03diff: drop line_prefix_length fieldJeff King3-8/+2
The diff_options structure holds a line_prefix string and an associated length. But the length is always just the strlen() of the NUL-terminated string. Let's simplify the code by just storing the string pointer and assuming it is NUL-terminated when we use it. This will cause us to compute the string length in a few extra spots, but I don't think any of these are particularly hot code paths. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-03line-log: use diff_line_prefix() instead of custom helperJeff King1-12/+2
Our local output_prefix() is exactly the same as the public diff_line_prefix() function. Let's just use that one, saving us a little bit of code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-03perl: fix a typoAndrew Kreimer1-1/+1
Fix a typo in comments. Signed-off-by: Andrew Kreimer <algonell@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-03mergetool: fix a typoAndrew Kreimer1-1/+1
Fix a typo in comments. Signed-off-by: Andrew Kreimer <algonell@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-03reftable: fix a typoAndrew Kreimer1-1/+1
Fix a typo in comments. Signed-off-by: Andrew Kreimer <algonell@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-03trace2: fix typosAndrew Kreimer2-2/+2
Fix typos in comments. Signed-off-by: Andrew Kreimer <algonell@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-03Documentation: mention the amlog in howto/maintain-git.txtTaylor Blau1-0/+44
Part of the maintainer's job is to keep up-to-date and publish the 'amlog' which stores a mapping between a patch's 'Message-Id' e-mail header and the commit generated by applying said patch. But our Documentation/howto/maintain-git.txt does not mention the amlog, or the scripts which exist to help the maintainer keep the amlog up-to-date. (This bit me during the first integration round I did as interim maintainer[1] involved a lot of manual clean-up. More recently it has come up as part of a research effort to better understand a patch's lifecycle on the list[2].) Address this gap by briefly documenting the existence and purpose of the 'post-applypatch' hook in maintaining the amlog entries. [1]: https://lore.kernel.org/git/Y19dnb2M+yObnftj@nand.local/ [2]: https://lore.kernel.org/git/CAJoAoZ=4ARuH3aHGe5yC_Xcnou_c396q_ZienYPY7YnEzZcyEg@mail.gmail.com/ Suggested-by: Junio C Hamano <gitster@pobox.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-03doc: add a note about staggering of maintenanceShubham Kanodia1-1/+3
Git maintenance tasks are staggered to a random minute of the hour per client to avoid thundering herd issues. Updates the doc to add a note about the same. Signed-off-by: Shubham Kanodia <shubham.kanodia10@gmail.com> Acked-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-03hash.h: set NEEDS_CLONE_HELPER_UNSAFE in fallback modeJeff King1-0/+3
Commit 253ed9ecff (hash.h: scaffolding for _unsafe hashing variants, 2024-09-26) introduced the concept of having two hash algorithms: a safe and an unsafe one. When the Makefile knobs do not explicitly request an unsafe one, we fall back to using the safe algorithm. However, the fallback to do so forgot one case: we should inherit the NEEDS_CLONE_HELPER flag from the safe variant. Failing to do so means that we'll end up defining two clone functions (the algorithm specific one, and the generic one that just calls memcpy). You'll see an error like this: $ make OPENSSL_SHA1=1 [...] sha1/openssl.h:46:29: error: redefinition of ‘openssl_SHA1_Clone’ 46 | #define platform_SHA1_Clone openssl_SHA1_Clone | ^~~~~~~~~~~~~~~~~~ hash.h:83:40: note: in expansion of macro ‘platform_SHA1_Clone’ 83 | # define platform_SHA1_Clone_unsafe platform_SHA1_Clone | ^~~~~~~~~~~~~~~~~~~ hash.h:101:33: note: in expansion of macro ‘platform_SHA1_Clone_unsafe’ 101 | # define git_SHA1_Clone_unsafe platform_SHA1_Clone_unsafe | ^~~~~~~~~~~~~~~~~~~~~~~~~~ hash.h:133:20: note: in expansion of macro ‘git_SHA1_Clone_unsafe’ 133 | static inline void git_SHA1_Clone_unsafe(git_SHA_CTX_unsafe *dst, | ^~~~~~~~~~~~~~~~~~~~~ sha1/openssl.h:37:20: note: previous definition of ‘openssl_SHA1_Clone’ with type ‘void(struct openssl_SHA1_CTX *, const struct openssl_SHA1_CTX *)’ 37 | static inline void openssl_SHA1_Clone(struct openssl_SHA1_CTX *dst, | ^~~~~~~~~~~~~~~~~~ This only matters when compiling with openssl as the "safe" variant, since it's the only algorithm that requires a clone helper (and even then, only if you are using openssl 3.0+). And you should never do that, because it's not safe. But still, the invocation above used to work and should continue to do so until we decide to require a collision-detecting variant for the safe algorithm entirely. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-03archive: fix misleading error messageRené Scharfe1-1/+2
The error message added by 296743a7ca (archive: load index before pathspec checks, 2024-09-21) is misleading: unpack_trees() is not touching the working tree at all here, but just loading a tree into the index. Correct it. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-03line-log: protect inner strbuf from freeDerrick Stolee2-6/+32
The output_prefix() method in line-log.c may call a function pointer via the diff_options struct. This function pointer returns a strbuf struct and then its buffer is passed back. However, that implies that the consumer is responsible to free the string. This is especially true because the default behavior is to duplicate the empty string. The existing functions used in the output_prefix pointer include: 1. idiff_prefix_cb() in diff-lib.c. This returns the data pointer, so the value exists across multiple calls. 2. diff_output_prefix_callback() in graph.c. This uses a static strbuf struct, so it reuses buffers across calls. These should not be freed. 3. output_prefix_cb() in range-diff.c. This is similar to the diff-lib.c case. In each case, we should not be freeing this buffer. We can convert the output_prefix() function to return a const char pointer and stop freeing the result. This choice is essentially the opposite of what was done in 394affd46d (line-log: always allocate the output prefix, 2024-06-07). This was discovered via 'valgrind' while investigating a public report of a bug in 'git log --graph -L' [1]. [1] https://github.com/git-for-windows/git/issues/5185 This issue would have been caught by the new test, when Git is compiled with ASan to catch these double frees. Co-authored-by: Jeff King <peff@peff.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-03l10n: tr: Update Turkish translations for 2.47.0Emir SARI1-58/+187
Signed-off-by: Emir SARI <emir_sari@icloud.com>
2024-10-02utf8.h: squelch unused-parameter warnings with NO_ICONVMike Hommey1-2/+3
Since DEVELOPER=YesPlease build enables -Wunused-parameter warnings these days, the fallback definition for reencode_string_len() that did not touch any of its parameters but one needs to be annotated properly. Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-02reftable/basics: ban standard allocator functionsPatrick Steinhardt2-0/+15
The reftable library uses pluggable allocators, which means that we shouldn't ever use the standard allocator functions. But it is an easy mistake to make to accidentally use e.g. free(3P) instead of the reftable-specific `reftable_free()` function, and we do not have any mechanism to detect this misuse right now. Introduce a couple of macros that ban the standard allocators, similar to how we do it in "banned.h". Note that we do not ban the following two classes of functions: - Macros like `FREE_AND_NULL()` or `REALLOC_ARRAY()`. As those expand to code that contains already-banned functions we'd get a compiler error even without banning those macros explicitly. - Git-specific allocators like `xmalloc()` and friends. The primary reason is that there are simply too many of them, so we're rather aiming for best effort here. Furthermore, the eventual goal is to make them unavailable in the reftable library place by not pulling them in via "git-compat-utils.h" anymore. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-02reftable: introduce `REFTABLE_FREE_AND_NULL()`Patrick Steinhardt9-18/+19
We have several calls to `FREE_AND_NULL()` in the reftable library, which of course uses free(3P). As the reftable allocators are pluggable we should rather call the reftable specific function, which is `reftable_free()`. Introduce a new macro `REFTABLE_FREE_AND_NULL()` and adapt the callsites accordingly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-02reftable: fix calls to free(3P)Patrick Steinhardt2-3/+3
There are a small set of calls to free(3P) in the reftable library. As the reftable allocators are pluggable we should rather call the reftable specific function, which is `reftable_free()`. Convert the code accordingly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-02reftable: handle trivial allocation failuresPatrick Steinhardt7-14/+67
Handle trivial allocation failures in the reftable library and its unit tests. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-02reftable/tree: handle allocation failuresPatrick Steinhardt4-26/+54
The tree interfaces of the reftable library handle both insertion and searching of tree nodes with a single function, where the behaviour is altered between the two via an `insert` bit. This makes it quit awkward to handle allocation failures because on inserting we'd have to check for `NULL` pointers and return an error, whereas on searching entries we don't have to handle it as an allocation error. Split up concerns of this function into two separate functions, one for inserting entries and one for searching entries. This makes it easy for us to check for allocation errors as `tree_insert()` should never return a `NULL` pointer now. Adapt callers accordingly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-02reftable/pq: handle allocation failures when adding entriesPatrick Steinhardt3-3/+11
Handle allocation failures when adding entries to the pqueue. Adapt its only caller accordingly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-02reftable/block: handle allocation failuresPatrick Steinhardt4-29/+69
Handle allocation failures in `block_writer_init()` and `block_reader_init()`. This requires us to bubble up error codes into `writer_reinit_block_writer()`. Adapt call sites accordingly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-02reftable/blocksource: handle allocation failuresPatrick Steinhardt1-5/+20
Handle allocation failures in the blocksource code. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-02reftable/iter: handle allocation failures when creating indexed table iterPatrick Steinhardt3-6/+23
Handle allocation failures in `new_indexed_table_ref_iter()`. While at it, rename the function to match our coding style. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-02reftable/stack: handle allocation failures in auto compactionPatrick Steinhardt1-4/+12
Handle allocation failures in `reftable_stack_auto_compact()`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-02reftable/stack: handle allocation failures in `stack_compact_range()`Patrick Steinhardt1-2/+17
Handle allocation failures in `stack_compact_range()`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-02reftable/stack: handle allocation failures in `reftable_new_stack()`Patrick Steinhardt1-8/+26
Handle allocation failures in `reftable_new_stack()`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-02reftable/stack: handle allocation failures on reloadPatrick Steinhardt1-9/+25
Handle allocation failures in `reftable_stack_reload_once()`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-02reftable/reader: handle allocation failures in `reader_init_iter()`Patrick Steinhardt5-30/+50
Handle allocation failures in `reader_init_iter()`. This requires us to also adapt `reftable_reader_init_*_iterator()` to bubble up the new error codes. Adapt callers accordingly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-02reftable/reader: handle allocation failures for unindexed readerPatrick Steinhardt1-6/+17
Handle allocation failures when creating unindexed readers. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-02reftable/merged: handle allocation failures in `merged_table_init_iter()`Patrick Steinhardt9-64/+131
Handle allocation failures in `merged_table_init_iter()`. While at it, merge `merged_iter_init()` into the function. It only has a single caller and merging them makes it easier to handle allocation failures consistently. This change also requires us to adapt `reftable_stack_init_*_iterator()` to bubble up the new error codes of `merged_table_iter_init()`. Adapt callsites accordingly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-02reftable/writer: handle allocation failures in `reftable_new_writer()`Patrick Steinhardt4-18/+38
Handle allocation failures in `reftable_new_writer()`. Adapt the function to return an error code to return such failures. While at it, rename it to match our code style as we have to touch up every callsite anyway. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-02reftable/writer: handle allocation failures in `writer_index_hash()`Patrick Steinhardt1-23/+38
Handle allocation errors in `writer_index_hash()`. Adjust its only caller in `reftable_writer_add_ref()` accordingly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-10-02reftable/record: handle allocation failures when decoding recordsPatrick Steinhardt1-17/+63
Handle allocation failures when decoding records. While at it, fix some error codes to be `REFTABLE_FORMAT_ERROR`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>