[pull] master from git:master#41
Merged
pull[bot] merged 20 commits intoturkdevops:masterfrom Apr 24, 2025
Merged
Conversation
Before accessing an array element at a given index, we should make sure that the index is within the desired bounds, otherwise it makes little sense to access the array element in the first place. In this instance, testing whether `ce->name[common]` is the trailing NUL byte is technically different from testing whether `common` is within the bounds of `previous_name`. It is also redundant, as the range-check guarantees that `previous_name->buf[common]` cannot be NUL and therefore the condition `ce->name[common] == previous_name->buf[common]` would not be met if `ce->name[common]` evaluated to NUL. However, in the interest of reducing the cognitive load to reason about the correctness of this loop (so that I can focus on interesting projects again), I'll simply move the range-check to the beginning of the loop condition and keep the redundant NUL check. This acquiesces CodeQL's `cpp/offset-use-before-range-check` rule. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 5dccd91 (t/perf: add iteration setup mechanism to perf-lib, 2022-04-04), perf tests need to declare their prerequisites with '--prereq', after the test title. p7821 was forgotten in that commit, such that running that test on a machine where the PCRE prereq is not satisfied aborts the test with: error: bug in the test script: test_wrapper_ needs 2 positional parameters Fix this by correcting the two 'test_perf' invocations in that test suite. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In p9210-scalar-clone.sh, we test using 'scalar clone' to clone $GIT_PERF_LARGE_REPO (copied locally as 'to-clone'), which defaults to the git.git checkout we are running the test from. When --branch is not specified (as in this test), 'scalar clone' tries to get the default branch of the remote repository by parsing the output of 'git ls-remote --symref $URL HEAD', as implemented in scalar.c:remote_default_branch. When the git.git checkout we are running the test from is in detached HEAD, this fails and we fall back to using the name of the currently checked out branch in the newly initialized repository, which in this case is the value returned earlier in cmd_clone by repo_default_branch_name. We then invoke 'git checkout -t origin/$branch', with $branch being the name we got from remote_default_branch. This invocation fails if '$branch' does not exist as a branch in the current git.git checkout. Fix this by creating a local branch in 'to-clone' in the setup test "enable server-side partial clone", making sure to use '-B' in case a branch named 'test-branch' already exists. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is a similar fix as 023756f (revision walker: --cherry-pick is a limited operation), but for the --left-only and --right-only options. When computing a symmetric difference between two unrelated histories, no suitable merge base exists, and so no boundary commit is flagged as UNINTERESTING. Previously, we relied on the presence of such boundary to trigger limiting and thus consideration of either "revs->left_only" or "revs->right_only". A number of other entries in the option parser have started including overrides for "revs->limited = 1". Do the same for these options. Signed-off-by: Matt Hunter <m@lfurio.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The commit b2a6d1c (bundle: allow the same ref to be given more than once, 2009-01-17) added functionality to detect and remove duplicate refnames from being added during bundle creation. This ensured that clones created from such bundles wouldn't barf about duplicate refnames. The following commit will add some optimizations to make this check faster, but before doing that, it would be optimal to add tests to capture the current behavior. Add tests to capture duplicate refnames provided by the user during bundle creation. This can be a combination of: - refnames directly provided by the user. - refname duplicate by using the '--all' flag alongside manual references being provided. - exclusion criteria provided via a refname "main^!". - short forms of refnames provided, "main" vs "refs/heads/main". Note that currently duplicates due to usage of short and long forms goes undetected. This should be fixed with the optimizations made in the next commit. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'git bundle create' command has non-linear performance with the number of refs in the repository. Benchmarking the command shows that a large portion of the time (~75%) is spent in the `object_array_remove_duplicates()` function. The `object_array_remove_duplicates()` function was added in b2a6d1c (bundle: allow the same ref to be given more than once, 2009-01-17) to skip duplicate refs provided by the user from being written to the bundle. Since this is an O(N^2) algorithm, in repos with large number of references, this can take up a large amount of time. Let's instead use a 'strset' to skip duplicates inside `write_bundle_refs()`. This improves the performance by around 6 times when tested against in repository with 100000 refs: Benchmark 1: bundle (refcount = 100000, revision = master) Time (mean ± σ): 14.653 s ± 0.203 s [User: 13.940 s, System: 0.762 s] Range (min … max): 14.237 s … 14.920 s 10 runs Benchmark 2: bundle (refcount = 100000, revision = HEAD) Time (mean ± σ): 2.394 s ± 0.023 s [User: 1.684 s, System: 0.798 s] Range (min … max): 2.364 s … 2.425 s 10 runs Summary bundle (refcount = 100000, revision = HEAD) ran 6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master) Previously, `object_array_remove_duplicates()` ensured that both the refname and the object it pointed to were checked for duplicates. The new approach, implemented within `write_bundle_refs()`, eliminates duplicate refnames without comparing the objects they reference. This works because, for bundle creation, we only need to prevent duplicate refs from being written to the bundle header. The `revs->pending` array can contain duplicates of multiple types. First, references which resolve to the same refname. For e.g. "git bundle create out.bdl master master" or "git bundle create out.bdl refs/heads/master refs/heads/master" or "git bundle create out.bdl master refs/heads/master". In these scenarios we want to prevent writing "refs/heads/master" twice to the bundle header. Since both the refnames here would point to the same object (unless there is a race), we do not need to check equality of the object. Second, refnames which are duplicates but do not point to the same object. This can happen when we use an exclusion criteria. For e.g. "git bundle create out.bdl master master^!", Here `revs->pending` would contain two elements, both with refname set to "master". However, each of them would be pointing to an INTERESTING and UNINTERESTING object respectively. Since we only write refnames with INTERESTING objects to the bundle header, we perform our duplicate checks only on such objects. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
- Switch the synopsis to a synopsis block which will automatically format placeholders in italics and keywords in monospace - Use _<placeholder>_ instead of <placeholder> in the description - Use `backticks` for keywords and more complex option descriptions. The new rendering engine will apply synopsis rules to these spans. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The synopsis analysis logic was not able to handle backslashes and stars which are used in the synopsis of the git-rm command. This patch fixes the issue by updating the regular expression used to match the keywords. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
- Switch the synopsis to a synopsis block which will automatically format placeholders in italics and keywords in monospace - Use _<placeholder>_ instead of <placeholder> in the description - Use `backticks` for keywords and more complex option descriptions. The new rendering engine will apply synopsis rules to these spans. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This also entails changing the help output for the command to match the new synopsis. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
- Switch the synopsis to a synopsis block which will automatically format placeholders in italics and keywords in monospace - Use _<placeholder>_ instead of <placeholder> in the description - Use `backticks` for keywords and more complex option descriptions. The new rendering engine will apply synopsis rules to these spans. Unfortunately, there's an inconsistency in the synopsis style, where the ellipsis is used to indicate that the option can be repeated, but it can also be used in Git's three-dot notation to indicate a range of commits. The rendering engine will not be able to distinguish between these two cases. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The processing of triple dot notation is tricky because it can be mis-interpreted as an ellipsis. The special processing of the ellipsis is now complete and takes into account the case of `git-mv <source>... <dest>` Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This rule was already implicitely applied in the converted man pages, so let's state it loudly. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In 7b31b55 (perf: amend the grep tests to test grep.threads, 2017-12-29), p7821 was tweaked to test the performance of 'git grep' under different number of threads. These tests are run if GIT_PERF_GREP_THREADS is set to a list of thread numbers, but the comment at the top of the file instead mentions GIT_PERF_7821_THREADS. Fix the comment. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
"make perf" fixes. * pb/perf-test-fixes: p7821: fix instructions for testing with threads p9210: fix 'scalar clone' when running from a detached HEAD p7821: fix test_perf invocation for prereqs
Optimize the code to dedup references recorded in a bundle file. * kn/bundle-dedup-optim: bundle: fix non-linear performance scaling with refs t6020: test for duplicate refnames in bundle creation
Doc mark-up updates. * ja/doc-reset-mv-rm-markup-updates: doc: add markup for characters in Guidelines doc: fix asciidoctor synopsis processing of triple-dots doc: convert git-mv to new documentation format doc: move synopsis git-mv commands in the synopsis section doc: convert git-rm to new documentation format doc: fix synopsis analysis logic doc: convert git-reset to new documentation format
Work around false positive from CodeQL checker. * js/range-check-codeql-workaround: read-cache: check range before dereferencing an array element
"git log --{left,right}-only A...B", when A and B does not share
any common ancestor, now behaves as expected.
* mh/left-right-limited:
revision: fix --left/right-only use with unrelated histories
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )