summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-04-16Merge branch 'dd/sparse-glibc-workaround'Junio C Hamano1-1/+1
Squelch false-positive from sparse. * dd/sparse-glibc-workaround: sparse: ignore warning from new glibc headers
2025-04-16t9811: be more precise to check importing of tagsAnthony Wang1-5/+4
The tests use grep to search the output of `git tag` for tagnames they expect to exist, which can incorrectly pass if an unxpected tag has the expected tag as its substring. We fix this by using `git show-ref --verify` instead. Additionally, we add a negative test to verify that a possible uninteded tag does not show up in the imported repository. This change also fixes an additional problem, where piping the output of `git tag` caused the exit codes to be lost. Signed-off-by: Anthony Wang <anthonywang513@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-16docs: document core.hooksPath=/dev/nullDerrick Stolee1-0/+5
If a user wishes to disable hooks, then they can do so using the established pattern of setting 'core.hooksPath' to /dev/null. This is already tested in t1350-config-hooks-path.sh, but has not previously been visible in the documentation. Update the documentation to include this as an option. Signed-off-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-16Documentation: stop depending on Perl to generate command listPatrick Steinhardt5-85/+109
The "cmd-list.perl" script is used to extract the list of commands part of a specific category and extracts the description of each command from its respective manpage. The generated output is then included in git(1) to list all Git commands. The script is written in Perl. Refactor it to use shell scripting exclusively so that we can get rid of the mandatory dependency on Perl to build our documentation. The converted script is slower compared to its Perl implementation. But by being careful and not spawning external commands in `format_one ()` we can mitigate the performance hit to a reasonable level: Benchmark 1: Perl Time (mean ± σ): 10.3 ms ± 0.2 ms [User: 7.0 ms, System: 3.3 ms] Range (min … max): 10.0 ms … 11.1 ms 200 runs Benchmark 2: Shell Time (mean ± σ): 74.4 ms ± 0.4 ms [User: 48.6 ms, System: 24.7 ms] Range (min … max): 73.1 ms … 75.5 ms 200 runs Summary Perl ran 7.23 ± 0.13 times faster than Shell While a sevenfold slowdown is significant, the benefit of not requiring Perl for a fully-functioning Git installation outweighs waiting a couple of milliseconds longer during the build process. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-16Documentation: stop depending on Perl to massage user manualPatrick Steinhardt3-17/+23
The "fix-texi.perl" script is used to fix up the output of `docbook2x-texi`: - It changes the filename to be "git.info". - It changes the directory category and entry. The script is written in Perl, but it can be rather trivially converted to a shell script. Do so to remove the dependency on Perl for building the user manual. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-16request-pull: stop depending on PerlPatrick Steinhardt2-37/+37
While git-request-pull(1) is written as a shell script, for it to function we depend on Perl being available. The script gets installed unconditionally though, regardless of whether or not Perl is even available on the system. When it's not available, the `@PERL_PATH@` variable may be substituted with a nonexistent executable path and thus cause the script to fail. Refactor the script so that it does not depend on Perl at all anymore. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-16filter-branch: stop depending on PerlPatrick Steinhardt1-18/+19
While git-filter-branch(1) is written as a shell script, the `--state-branch` feature depends on Perl to save and extract the object ID mappings. This can lead to subtle breakage though: - We execute `perl` directly without respecting the `PERL_PATH` configured by the distribution. As such, it may happen that we use the wrong version of Perl. - We install the script unchanged even if Perl isn't available at all on the system, so using `--state-branch` would lead to failure altogether in that case. Fix this by dropping Perl and instead implementing the feature with shell scripting exclusively. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-16ci(pedantic): ensure that awk is installedJohannes Schindelin1-1/+1
The image pointed to by the fedora:latest tag has moved from fedora 41 to 42. The fedora 41 container images have awk installed while the fedora 42 images do not. That change is most likely just part of reducing the size of the base container images. In both AlmaLinux and Fedora (as well as other RHEL derivatives/relatives), awk is provided by the gawk package. On Fedora, `dnf install awk` would work, by using the package filelist data to determine that /usr/bin/awk is provided by gawk and installs gawk as a result. On AlmaLinux (8 & 9, by quick testing by Todd), that is not the case and you'd need to use `dnf install gawk` or `dnf install '*bin/awk'` to get it installed. Having said that, awk _is_ included in the current AlmaLinux 8 and 9 images, so it isn't strictly needed. But it's probably better to be explicit that we need it installed, as a defense against some future change to the AlmaLinux container removing awk. Because we know that on both of these distros, our scripts that call for 'awk' had been using 'gawk' that was installed as part of the base image, let's make sure that we explicitly install 'gawk'. If the image already has it, it would be a no-op that does not cause breakage. Suggested-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-15The fifth batchJunio C Hamano1-0/+29
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-15Merge branch 'bc/allow-upload-pack-from-other-people'Junio C Hamano1-3/+2
Test fix for an already graduated topic. * bc/allow-upload-pack-from-other-people: t5605: fix test for cloning from a different user
2025-04-15Merge branch 'pw/custom-conflict-marker-size-for-merge-related-docs'Junio C Hamano1-0/+1
"git-merge-file" documentation source, which has lines that look like conflict markers, lacked custom conflict marker size defined, which has been corrected.. * pw/custom-conflict-marker-size-for-merge-related-docs: merge-file doc: set conflict-marker-size attribute
2025-04-15Merge branch 'js/comma-semicolon-confusion'Junio C Hamano12-51/+88
Code clean-up. * js/comma-semicolon-confusion: detect-compiler: detect clang even if it found CUDA clang: warn when the comma operator is used compat/regex: explicitly mark intentional use of the comma operator wildmatch: avoid using of the comma operator diff-delta: avoid using the comma operator xdiff: avoid using the comma operator unnecessarily clar: avoid using the comma operator unnecessarily kwset: avoid using the comma operator unnecessarily rebase: avoid using the comma operator unnecessarily remote-curl: avoid using the comma operator unnecessarily
2025-04-15Merge branch 'jt/clone-guess-remote-head-fix'Junio C Hamano10-13/+44
"git clone" still gave the message about the default branch name; this message has been turned into an advice message that can be turned off. * jt/clone-guess-remote-head-fix: advice: allow disabling default branch name advice builtin/clone: suppress unexpected default branch advice remote: allow `guess_remote_head()` to suppress advice
2025-04-15Merge branch 'ds/maintenance-loose-objects-batchsize'Junio C Hamano4-7/+64
The job to coalesce loose objects into packfiles in "git maintenance" now has configurable batch size. * ds/maintenance-loose-objects-batchsize: maintenance: add loose-objects.batchSize config maintenance: force progress/no-quiet to children
2025-04-15Merge branch 'lo/userdiff-gitconfig'Junio C Hamano6-0/+42
* lo/userdiff-gitconfig: userdiff: add builtin driver for INI files
2025-04-15Merge branch 'ps/mingw-creat-excl-fix'Junio C Hamano2-1/+23
Fix lockfile contention in reftable code on Windows. * ps/mingw-creat-excl-fix: compat/mingw: fix EACCESS when opening files with `O_CREAT | O_EXCL` meson: fix compat sources when compiling with MSVC
2025-04-15Merge branch 'kn/reflog-drop'Junio C Hamano3-8/+209
"git reflog" learns "drop" subcommand, that discards the entire reflog data for a ref. * kn/reflog-drop: reflog: implement subcommand to drop reflogs reflog: improve error for when reflog is not found
2025-04-15Merge branch 'ps/object-wo-the-repository'Junio C Hamano87-613/+677
The object layer has been updated to take an explicit repository instance as a parameter in more code paths. * ps/object-wo-the-repository: hash: stop depending on `the_repository` in `null_oid()` hash: fix "-Wsign-compare" warnings object-file: split out logic regarding hash algorithms delta-islands: stop depending on `the_repository` object-file-convert: stop depending on `the_repository` pack-bitmap-write: stop depending on `the_repository` pack-revindex: stop depending on `the_repository` pack-check: stop depending on `the_repository` environment: move access to "core.bigFileThreshold" into repo settings pack-write: stop depending on `the_repository` and `the_hash_algo` object: stop depending on `the_repository` csum-file: stop depending on `the_repository`
2025-04-15Merge branch 'md/t1403-path-is-file'Junio C Hamano1-1/+1
Test tweak. * md/t1403-path-is-file: t1403: verify that path exists and is a file
2025-04-15Merge branch 'jk/zlib-inflate-fixes'Junio C Hamano3-36/+92
Fix our use of zlib corner cases. * jk/zlib-inflate-fixes: unpack_loose_rest(): rewrite return handling for clarity unpack_loose_rest(): simplify error handling unpack_loose_rest(): never clean up zstream unpack_loose_rest(): avoid numeric comparison of zlib status unpack_loose_header(): avoid numeric comparison of zlib status git_inflate(): skip zlib_post_call() sanity check on Z_NEED_DICT unpack_loose_header(): fix infinite loop on broken zlib input unpack_loose_header(): report headers without NUL as "bad" unpack_loose_header(): simplify next_out assignment loose_object_info(): BUG() on inflating content with unknown type
2025-04-15Merge branch 'ps/reftable-windows-unlink-fix'Junio C Hamano3-3/+11
Portability fix. * ps/reftable-windows-unlink-fix: reftable: ignore file-in-use errors when unlink(3p) fails on Windows
2025-04-15Merge branch 'ps/test-wo-perl-prereq' into ps/fewer-perlJunio C Hamano84-373/+471
* ps/test-wo-perl-prereq: t5703: refactor test to not depend on Perl t5316: refactor `max_chain()` to not depend on Perl t0210: refactor trace2 scrubbing to not use Perl t0021: refactor `generate_random_characters()` to not depend on Perl t/lib-httpd: refactor "one-time-perl" CGI script to not depend on Perl t/lib-t6000: refactor `name_from_description()` to not depend on Perl t/lib-gpg: refactor `sanitize_pgp()` to not depend on Perl t: refactor tests depending on Perl for textconv scripts t: refactor tests depending on Perl to print data t: refactor tests depending on Perl substitution operator t: refactor tests depending on Perl transliteration operator Makefile: stop requiring Perl when running tests meson: stop requiring Perl when tests are enabled t: adapt existing PERL prerequisites t: introduce PERL_TEST_HELPERS prerequisite t: adapt `test_readlink()` to not use Perl t: adapt `test_copy_bytes()` to not use Perl t: adapt character translation helpers to not use Perl t: refactor environment sanitization to not use Perl t: skip chain lint when PERL_PATH is unset
2025-04-15object-store: merge "object-store-ll.h" and "object-store.h"Patrick Steinhardt124-642/+637
The "object-store-ll.h" header has been introduced to keep transitive header dependendcies and compile times at bay. Now that we have created a new "object-store.c" file though we can easily move the last remaining additional bit of "object-store.h", the `odb_path_map`, out of the header. Do so. As the "object-store.h" header is now equivalent to its low-level alternative we drop the latter and inline it into the former. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-15object-store: remove global array of cached objectsPatrick Steinhardt3-18/+37
Cached objects are virtual objects that can be set up without writing anything into the object store directly, which is used by git-blame(1) to create fake commits for the working tree. These cached objects are stored in a global variable, which is another roadblock for libification of the object subsystem. Refactor the code so that we instead store the array as part of the raw object store. This refactoring raises the question whether virtual objects should really be specific to a single repository (or rather a single object store). Hypothetical usecases might for example span across submodules, and here it may or may not be the right thing to provide virtual objects across submodule boundaries. The only existing usecase is git-blame(1) though, which does not know to blame across submodule boundaries in the first place. As such, storing these objects both globally and per-repository would achieve the same result right now. But arguably, if we learned to blame across submodule boundaries, we would likely want to create separate fare working tree commits for each of the submodules so that the user can learn which worktree a specific uncommitted change belongs to. And even if we would want to create the same fake commit for each of the submodules we could do that when storing separate virtual objects per object store. While this is all rather hypothetical, the takeaway is that handling virtual objects per-object store gives us more flexibility compared to storing them globally. In a hypothetical future where we have achieved full libification one might be able to handle unrelated repositories in a single process, where the state of one repository should not have an impact on the state of another repository. As such, storing these cached objects per object store will enable more usecases and should lead to less surprising outcomes overall. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-15object: split out functions relating to object store subsystemPatrick Steinhardt3-70/+66
Split out functions relating to the object store subsystem from "object.c". This helps us to separate concerns. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-15object-file: drop `index_blob_stream()`Patrick Steinhardt2-24/+17
The `index_blob_stream()` function is a mere wrapper around `index_blob_bulk_checkin()`. This has been the case since 568508e7657 (bulk-checkin: replace fast-import based implementation, 2011-10-28), which has moved the implementation from `index_blob_stream()` (which was still called `index_stream()`) into `index_bulk_checkin()` (which has since been renamed to `index_blob_bulk_checkin()`). Remove the redirection by dropping the wrapper. Move the comment to `index_blob_bulk_checkin()` to retain its context. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-15object-file: split up concerns of `HASH_*` flagsPatrick Steinhardt9-28/+56
The functions `hash_object_file()`, `write_object_file()` and `index_fd()` reuse the same set of flags to alter their behaviour. This not only adds confusion, but given that every function only supports a subset of the flags it becomes very hard to see which flags can be passed to what function. Last but not least, this entangles the implementation of all three function families. Split up concerns by creating separate flags for each of the function families. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-15object-file: split out functions relating to object store subsystemPatrick Steinhardt20-1040/+1074
While we have the "object-store.h" header, most of the functionality for object stores is actually hosted in "object-file.c". This makes it hard to find relevant functions and causes us to mix up concerns. Split out functions relating to the object store subsystem into a new "object-store.c" file. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-15object-file: move `xmmap()` into "wrapper.c"Patrick Steinhardt2-48/+48
The `xmmap()` function is provided by "object-file.c" even though its functionality has nothing to do with the object file subsystem. Move it into "wrapper.c", whose header already declares those functions. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-15object-file: move `git_open_cloexec()` to "compat/open.c"Patrick Steinhardt11-36/+34
The `git_open_cloexec()` wrapper function provides the ability to open a file with `O_CLOEXEC` in a platform-agnostic way. This function is provided by "object-file.c" even though it is not specific to the object subsystem at all. Move the file into "compat/open.c". This file already exists before this commit, but has only been compiled conditionally depending on whether or not open(3p) may return EINTR. With this change we now unconditionally compile the object, but wrap `git_open_with_retry()` in an ifdef. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-15object-file: move `safe_create_leading_directories()` into "path.c"Patrick Steinhardt27-167/+173
The `safe_create_leading_directories()` function and its relatives are located in "object-file.c", which is not a good fit as they provide generic functionality not related to objects at all. Move them into "path.c", which already hosts `safe_create_dir()` and its relative `safe_create_dir_in_gitdir()`. "path.c" is free of `the_repository`, but the moved functions depend on `the_repository` to read the "core.sharedRepository" config. Adapt the function signature to accept a repository as argument to fix the issue and adjust callers accordingly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-15object-file: move `mkdir_in_gitdir()` into "path.c"Patrick Steinhardt6-36/+47
The `mkdir_in_gitdir()` function is similar to `safe_create_dir()`, but the former is hosted in "object-file.c" whereas the latter is hosted in "path.c". The latter code unit makes way more sense though as the logic has nothing to do with object files in particular. Move the file into "path.c". While at it, we: - Rename the function to `safe_create_dir_in_gitdir()` so that the function names are similar to one another. - Remove the dependency on `the_repository` by making the callers pass the repository instead. Adjust callers accordingly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-14p7821: fix instructions for testing with threadsPhilippe Blain1-1/+1
In 7b31b55db1 (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>
2025-04-14doc: add markup for characters in GuidelinesJean-Noël Avila1-0/+3
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>
2025-04-14doc: fix asciidoctor synopsis processing of triple-dotsJean-Noël Avila2-4/+6
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>
2025-04-14doc: convert git-mv to new documentation formatJean-Noël Avila2-16/+17
- 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>
2025-04-14doc: move synopsis git-mv commands in the synopsis sectionJean-Noël Avila2-5/+4
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>
2025-04-14doc: convert git-rm to new documentation formatJean-Noël Avila1-28/+28
- 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>
2025-04-14doc: fix synopsis analysis logicJean-Noël Avila2-7/+7
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>
2025-04-14doc: convert git-reset to new documentation formatJean-Noël Avila1-49/+49
- 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>
2025-04-09environment.h: remove unused variablesArnav Bhate1-2/+0
packed_git_window_size and packed_git_limit are not used anywhere in the codebase. A search found that all references were removed in d284713bae (config: make `packed_git_(limit|window_size)` non-global variables, 2024-12-03), except the ones in this file, as they were moved to struct repo_settings. Remove packed_git_window_size and packed_git_limit from environment.h. Signed-off-by: Arnav Bhate <bhatearnav@gmail.com> Acked-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-09refs: fix duplicated word in commentChristian Fredrik Johnsen1-2/+2
Fix a typo in a comment in refs.c: "checking checking" → "checking". Signed-off-by: Christian Fredrik Johnsen <christian@johnsen.no> Acked-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-09refs/packed: fix BUG when seeking refs with UTF-8 charactersPatrick Steinhardt2-2/+17
It was reported that using git-pull(1) in a repository whose remote contains branches with emojis leads to the following bug: $ git pull remote: Enumerating objects: 161255, done. remote: Counting objects: 100% (55884/55884), done. remote: Compressing objects: 100% (5518/5518), done. remote: Total 161255 (delta 54253), reused 50509 (delta 50364), pack-reused 105371 (from 4) Receiving objects: 100% (161255/161255), 309.90 MiB | 16.87 MiB/s, done. Resolving deltas: 100% (118048/118048), completed with 13416 local objects. From github.com:github/github 97ab7ae3f3745..8fb2f9fa180ed master -> origin/master [...snip many screenfuls of updates to origin remotes...] BUG: refs/packed-backend.c:984: packed-refs backend yielded reference preceding its prefix error: fetch died of signal 6 This issue bisects to 22600c04529 (refs/iterator: implement seeking for packed-ref iterators, 2025-03-12) where we have implemented seeking for the packed-ref iterator. As part of that change we introduced a check that verifies that the iterator only returns refnames bigger than the prefix. In theory, this check should always hold: when a prefix is set we know that we would've seeked that prefix first, so we should never see a reference sorting before that prefix. But in practice the check itself is misbehaving when handling unicode characters. The particular issue triggered with a branch that got the "shaved ice" unicode character in its name, which is composed of the bytes "0xEE 0x90 0xBF". The bug triggers when we compare the refname "refs/heads/<shaved-ice>" to something like "refs/heads/z", and it specifically hits when comparing the first byte, "0xEE". The root cause is that the most-significant bit of 0xEE is set. The `refname` and `prefix` pointers that we use to compare bytes with one another are both pointers to signed characters. As such, when we dereference the 0xEE byte the result is a _negative_ value, and this value will of course compare smaller than "z". We can see that this issue is avoided in `cmp_packed_refname()`, where we explicitly cast each byte to its unsigned form. Fix the bug by doing the same in `packed_ref_iterator_advance()`. Reported-by: Elijah Newren <newren@gmail.com> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-09fetch: make set_head() call easier to readJeff King1-4/+5
We ignore any error returned from set_head(), but 638060dcb9 (fetch set_head: refactor to use remote directly, 2025-01-26) left its call in a noop "if" conditional as a sort of note-to-self. When c834d1a7ce (fetch: only respect followRemoteHEAD with configured refspecs, 2025-03-18) added a "do_set_head" flag, it was rolled into the same conditional, putting set_head() on the right-hand side of a short-circuit AND. That's not wrong, but it really hides the point of the line, which is (maybe) calling the function. Instead, let's have a full if() block for the flag, and then our comment (with some rewording) will be sufficient to clarify the error handling. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-09ci: upgrade `sparse` to supported build agentsJohannes Schindelin2-11/+2
The `sparse` job still uses the `ubuntu-20.04` runner pool, but that pool is about to go away, so let's stop using it. There is no `sparse-22.04` artifact provided by the "Build sparse for Ubuntu" Azure Pipeline, but that is not necessary anyway because Ubuntu 22.04 has the `sparse` package: https://packages.ubuntu.com/jammy/sparse Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-09sparse: ignore warning from new glibc headersĐoàn Trần Công Danh1-1/+1
With at least glibc 2.39, glibc provides a function declaration that matches with this POSIX interface: int regexec(const regex_t *restrict preg, const char *restrict string, size_t nmatch, regmatch_t pmatch[restrict], int eflags); such prototype requires variable-length-array for `pmatch'. Thus, sparse reports this error: > ../add-patch.c: note: in included file (through ../git-compat-util.h): > /usr/include/regex.h:682:41: error: undefined identifier '__nmatch' > /usr/include/regex.h:682:41: error: bad constant expression type > /usr/include/regex.h:682:41: error: Variable length array is used. Note: `__nmatch' is POSIX's nmatch. The glibc's intention is informing their users to provides a large enough buffer to hold `__nmatch' results and provides diagnosis if necessary. It's merely a glibc' implementation detail. Hide that usage from sparse by using standard C11's macro: __STDC_NO_VLA__ Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-08builtin/update-server-info: remove unnecessary if statementUsman Akinyemi2-2/+9
Since we already teach the `repo_config()` in f29f1990 (config: teach repo_config to allow `repo` to be NULL, 2025-03-08) to allow `repo` to be NULL, no need to check if `repo` is NULL before calling `repo_config()`. Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Usman Akinyemi <usmanakinyemi202@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-08Merge branch 'ps/object-wo-the-repository' into ps/object-file-cleanupJunio C Hamano87-613/+677
* ps/object-wo-the-repository: hash: stop depending on `the_repository` in `null_oid()` hash: fix "-Wsign-compare" warnings object-file: split out logic regarding hash algorithms delta-islands: stop depending on `the_repository` object-file-convert: stop depending on `the_repository` pack-bitmap-write: stop depending on `the_repository` pack-revindex: stop depending on `the_repository` pack-check: stop depending on `the_repository` environment: move access to "core.bigFileThreshold" into repo settings pack-write: stop depending on `the_repository` and `the_hash_algo` object: stop depending on `the_repository` csum-file: stop depending on `the_repository`
2025-04-08bundle: fix non-linear performance scaling with refsKarthik Nayak4-44/+7
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 b2a6d1c686 (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>
2025-04-08t6020: test for duplicate refnames in bundle creationKarthik Nayak1-0/+57
The commit b2a6d1c686 (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>