git, branch v2.38.0-rc2

Git 2.38-rc2

2022-09-27T18:25:52Z

We have small updates since -rc1 but none of them is about a new thing and there is no updates to the release notes. Signed-off-by: Junio C Hamano

Merge branch 'ds/bitmap-lookup-remove-tracing'

2022-09-27T04:46:51Z

Perf-fix. * ds/bitmap-lookup-remove-tracing: pack-bitmap: remove trace2 region from hot path

pack-bitmap: remove trace2 region from hot path

2022-09-26T19:09:18Z

The trace2 region around the call to lazy_bitmap_for_commit() in bitmap_for_commit() was added in 28cd730680d (pack-bitmap: prepare to read lookup table extension, 2022-08-14). While adding trace2 regions is typically helpful for tracking performance, this method is called possibly thousands of times as a commit walk explores commit history looking for a matching bitmap. When trace2 output is enabled, this region is emitted many times and performance is throttled by that output. For now, remove these regions entirely. This is a critical path, and it would be valuable to measure that the time spent in bitmap_for_commit() does not increase when using the commit lookup table. The best way to do that would be to use a mechanism that sums the time spent in a region and reports a single value at the end of the process. This technique was introduced but not merged by [1] so maybe this example presents some justification to revisit that approach. [1] https://lore.kernel.org/git/pull.1099.v2.git.1640720202.gitgitgadget@gmail.com/ To help with the 'git blame' output in this region, add a comment that warns against adding a trace2 region. Delete a test from t5310 that used that trace output to check that this lookup optimization was activated. To create this kind of test again in the future, the stopwatch traces mentioned earlier could be used as a signal that we activated this code path. Helpedy-by: Junio C Hamano Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

Merge branch 'ac/bitmap-lookup-table'

2022-09-23T18:07:49Z

Grammofix. * ac/bitmap-lookup-table: pack-bitmap: improve grammar of "xor chain" error message

Merge branch 'ma/scalar-to-main-fix'

2022-09-23T18:07:48Z

Fix manpage generation. * ma/scalar-to-main-fix: cmd-list.perl: fix identifying man sections

cmd-list.perl: fix identifying man sections

2022-09-23T17:01:07Z

We attribute each documentation text file to a man section by finding a line in the file that looks like "gitfoo()". Commit cc75e556a9 ("scalar: add to 'git help -a' command list", 2022-09-02) updated this logic to look not only for "gitfoo" but also "scalarfoo". In doing so, it forgot to account for the fact that after the updated regex has found a match, the man section is no longer to be found in `$1` but now lives in `$2`. This makes our git(1) manpage look as follows: Main porcelain commands git-add(git) Add file contents to the index. [...] gitk(git) The Git repository browser. scalar(scalar) A tool for managing large Git repositories. Restore the man sections by not capturing the (git|scalar) part of the match into `$1`. As noted by Ævar [1], we could even match any "foo" rather than just "gitfoo" and "scalarfoo", but that's a larger change. For now, just fix the regression in cc75e556a9. [1] https://lore.kernel.org/git/220923.86wn9u4joo.gmgdl@evledraar.gmail.com/#t Helped-by: Ævar Arnfjörð Bjarmason Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano

pack-bitmap: improve grammar of "xor chain" error message

2022-09-23T15:54:05Z

Signed-off-by: Alex Henrie Signed-off-by: Junio C Hamano

Merge branch 'jk/list-objects-filter-cleanup'

2022-09-22T22:30:47Z

Fix uninitialized memory access in a recent fix-up that is already in -rc1. * jk/list-objects-filter-cleanup: list-objects-filter: initialize sub-filter structs

list-objects-filter: initialize sub-filter structs

2022-09-22T19:43:04Z

Since commit c54980ab83 (list-objects-filter: convert filter_spec to a strbuf, 2022-09-11), building with SANITIZE=undefined triggers an error in t5616. The problem is that we end up with a strbuf that has been zero-initialized instead of via STRBUF_INIT. Feeding that strbuf to strbuf_addbuf() in list_objects_filter_copy() means we will call memcpy like: memcpy(some_actual_buffer, NULL, 0); This works on most systems because we're copying zero bytes, but it is technically undefined behavior to ever pass NULL to memcpy. Even though c54980ab83 is where the bug manifests, that is only because we switched away from a string_list, which is OK with being zero-initialized (though it may cause other problems by not duplicating the strings, it happened to be OK in this instance). The actual bug is caused by the commit before that, 2a01bdedf8 (list-objects-filter: add and use initializers, 2022-09-11). There we consistently initialize the top-level filter structs, but we forgot the dynamically allocated ones we stick in filter_options->sub when creating combined filters. Note that we need to fix two spots here: where we parse a "combine:" filter, but also where we transform from a single-filter into a combined one after seeing multiple "--filter" options. In the second spot, we'll do some minor refactoring to avoid repeating our very-long array index. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Git 2.38-rc1

2022-09-21T22:27:03Z

Signed-off-by: Junio C Hamano