summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-04-07reftable/block: simplify how we track restart pointsPatrick Steinhardt3-17/+18
Restart points record the location of reftable records that do not use prefix compression and are used to perform a binary search inside of a block. These restart points are encoded at the end of a block, between the record data and the footer of a table. The block structure contains three different variables related to these restart points: - The block length contains the length of the reftable block up to the restart points. - The restart count contains the number of restart points contained in the block. - The restart bytes variable tracks where the restart point data begins. Tracking all three of these variables is unnecessary though as the data can be derived from one another: the block length without restart points is the exact same as the offset of the restart count data, which we already track via the `restart_bytes` data. Refactor the code so that we track the location of restart bytes not as a pointer, but instead as an offset. This allows us to trivially get rid of the `block_len` variable as described above. This avoids having the confusing `block_len` variable and allows us to do less bookkeeping overall. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07reftable/blocksource: consolidate code into a single filePatrick Steinhardt10-62/+80
The code that implements block sources is distributed across a couple of files. Consolidate all of it into "reftable/blocksource.c" and its accompanying header so that it is easier to locate and more self contained. While at it, rename some of the functions to have properly scoped names. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07reftable/reader: rename data structure to "table"Patrick Steinhardt19-467/+467
The `struct reftable_reader` subsystem encapsulates a table that has been read from the disk. As such, the current name of that structure is somewhat hard to understand as it only talks about the fact that we read something from disk, without really giving an indicator _what_ that is. Furthermore, this naming schema doesn't really fit well into how the other structures are named: `reftable_merged_table`, `reftable_stack`, `reftable_block` and `reftable_record` are all named after what they encapsulate. Rename the subsystem to `reftable_table`, which directly gives a hint that the data structure is about handling the individual tables part of the stack. While this change results in a lot of churn, it prepares for us exposing the APIs to third-party callers now that the reftable library is a standalone library that can be linked against by other projects. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07reftable: fix formatting of the license headerPatrick Steinhardt34-199/+199
The license headers used across the reftable library doesn't follow our typical coding style for multi-line comments. Fix it. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07blame: print unblamable and ignored commits in porcelain modeKarthik Nayak4-5/+60
The 'git-blame(1)' command allows users to ignore specific revisions via the '--ignore-rev <rev>' and '--ignore-revs-file <file>' flags. These flags are often combined with the 'blame.markIgnoredLines' and 'blame.markUnblamableLines' config options. These config options prefix ignored and unblamable lines with a '?' and '*', respectively. However, this option was never extended to the porcelain mode of 'git-blame(1)'. Since the documentation does not indicate this exclusion, it is a bug. Fix this by printing 'ignored' and 'unblamable' respectively for the options when using the porcelain modes. Helped-by: Patrick Steinhardt <ps@pks.im> Helped-by: Toon Claes <toon@iotcl.com> Helped-by: Phillip Wood <phillip.wood123@gmail.com> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t5703: refactor test to not depend on PerlPatrick Steinhardt1-17/+8
We use Perl due to two different reasons in t5703: - To filter advertised capabilities. - To set up a CGI script with HTTPD. Refactor the first category to use `test_grep` instead. Refactoring the second category would be a bit more involved, so instead we add the PERL_TEST_HELPERS prerequisite to those individual tests now. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t5316: refactor `max_chain()` to not depend on PerlPatrick Steinhardt1-9/+9
The `max_chain()` helper function is used to extract the maximum delta chain of a packfile as printed by git-index-pack(1). The script uses Perl to extract that data, but it can be trivially refactored to use awk(1) instead. Refactor the helper accordingly so that we can drop a couple of PERL_TEST_HELPERS prerequisites. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t0210: refactor trace2 scrubbing to not use PerlPatrick Steinhardt2-72/+43
The output generated by our trace2 mechanism contains several fields that are dependent on the environment they're being run in, which makes it somewhat harder to test it. As a countermeasure we scrub the output and strip out any fields that contain such information. The logic to do so is implemented in Perl, but it can be trivially ported to instead use sed(1). Refactor the code accordingly so that we can drop the PERL_TEST_HELPERS prerequisite. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t0021: refactor `generate_random_characters()` to not depend on PerlPatrick Steinhardt1-4/+3
The `generate_random_characters()` helper function generates N random characters in the range 'a-z' and writes them into a file. The logic currently uses Perl, but it can be adapted rather easily by: - Making `test-tool genrandom` generate an infinite stream. - Using `tr -dc` to strip all characters which aren't in the range of 'a-z'. - Using `test_copy_bytes()` to copy the first N bytes. This allows us to drop the PERL_TEST_HELPERS prerequisite. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t/lib-httpd: refactor "one-time-perl" CGI script to not depend on PerlPatrick Steinhardt8-77/+86
Our Apache HTTPD setup exposes an "one_time_perl" endpoint to access repositories. If used, we execute the "apply-one-time-perl.sh" CGI script that checks whether we have a "one-time-perl" script. If so, that script gets executed so that it can munge what would be served. Once done, the script gets removed so that it doesn't execute a second time. As the name says, this functionality expects the user to pass a Perl script. This isn't really necessary though: we can just as easily implement the same thing with arbitrary scripts. Refactor the code so that we instead expect an arbitrary script to exist and rename the functionality to "one-time-script". Adapt callers to use shell utilities instead of Perl so that we can drop the PERL_TEST_HELPERS prerequisite. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t/lib-t6000: refactor `name_from_description()` to not depend on PerlPatrick Steinhardt3-19/+6
The `name_from_description()` test helper uses Perl to munge a given description and convert it into a name. Refactor it to instead use a combination of sed(1) and tr(1) so that we drop PERL_TEST_HELPERS prerequisites in users of this library. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t/lib-gpg: refactor `sanitize_pgp()` to not depend on PerlPatrick Steinhardt2-16/+11
The `sanitize_pgp()` test helper uses Perl to strip PGP signatures from stdin. Refactor it to instead use sed(1) so that we drop the PERL_TEST_HELPERS prerequisite in users of this library. Note that we have to add PERL_TEST_HELPERS to a subset of tests in t6300 now that the test suite doesn't bail out early anymore in case the prerequisite isn't set. Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t: refactor tests depending on Perl for textconv scriptsPatrick Steinhardt3-36/+13
We have a couple of tests that depend on Perl for textconv scripts. Refactor these tests to instead be implemented via shell utilities so that we can drop a couple of PERL_TEST_HELPERS prerequisites. Note that the conversion in t4030 is not a one-to-one equivalent to the previous textconv script. Before this change we used to essentially do a hexdump via Perl. The obvious conversion here would be to use `test-tool hexdump` like we do for the other tests. But this would lead to a ripple effect where we would have to adapt a bunch of other tests with a bunch of seemingly unrelated changes, which would be somewhat awkward. Instead, we're going with the minimum viable change: the test files we write contain "\001" and "\000", and the test's expectation is that those get translated into proper ASCII characters. So instead of doing a full hexdump, we simply use tr(1) to translate these specific bytes. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t: refactor tests depending on Perl to print dataPatrick Steinhardt14-67/+51
A bunch of tests rely on Perl to print data in various different ways. These usages fall into the following categories: - Print data conditionally by matching patterns. These usecases can be converted to use awk(1) rather easily. - Print data repeatedly. These usecases can typically be converted to use a combination of `test-tool genzeros` and sed(1). - Print data in reverse. These usecases can be converted to use awk(1) or `sort -r`. Refactor the tests accordingly so that we can drop a couple of PERL_TEST_HELPERS prerequisites. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t: refactor tests depending on Perl substitution operatorPatrick Steinhardt11-60/+40
We have a bunch of tests that use Perl to perform substitution via the "s/" operator. These usecases can be trivially replaced with sed(1) and tr(1). Refactor the tests accordingly so that we can drop a couple of PERL_TEST_HELPERS prerequisites. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t: refactor tests depending on Perl transliteration operatorPatrick Steinhardt7-31/+19
We have a bunch of tests that use Perl to perform character transliteration via the "y/" or "tr/" operator. These usecases can be trivially replaced with tr(1). Refactor the tests accordingly so that we can drop a couple of PERL_TEST_HELPERS prerequisites. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07Makefile: stop requiring Perl when running testsPatrick Steinhardt1-3/+13
The Makefile for our tests has a couple of targets that depend on Perl. Adapt those targets to only run conditionally in case Perl is available on the system so that it becomes possible to run the test suite without Perl. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07meson: stop requiring Perl when tests are enabledPatrick Steinhardt1-1/+1
The Perl interpreter used to be a strict dependency for running our test suite. This requirement is explicit in the Meson build system, where we require Perl to be present unless tests have been disabled. With the preceding commits we have loosened this restriction so that it is now possible to run tests when Perl is unavailable. Loosen the above requirement accordingly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t: adapt existing PERL prerequisitesPatrick Steinhardt4-15/+19
A couple of our tests depend on the PERL prerequisite even though it isn't needed. These tests fall into one of the following classes: - The underlying logic used to be implemented in Perl but isn't anymore. Here we can simply drop the dependency altogether. - The test logic used to depend on Perl but doesn't anymore. Again, we can simply drop the dependency. - The test logic still relies on a Perl interpreter. These tests should use the newly introduced PERL_TEST_HELPERS prerequisite. Adapt test cases accordingly. Note that in t1006 we have to introduce another new prerequisite depending on whether or not the IPC::Open2 module is available. Funny enough, when starting to use `test_lazy_prereq` to do so we also get a conflict of variables with the "script" variable that contains the Perl logic because `test_run_lazy_prereq_` also sets that variable. We thus rename the variable in t1006 to "perl_script". Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t: introduce PERL_TEST_HELPERS prerequisitePatrick Steinhardt71-93/+281
In the early days of Git, Perl was used quite prominently throughout the project. This has changed significantly as almost all of the executables we ship nowadays have eventually been rewritten in C. Only a handful of subsystems remain that require Perl: - gitweb, a read-only web interface. - A couple of scripts that allow importing repositories from GNU Arch, CVS and Subversion. - git-send-email(1), which can be used to send mails. - git-request-pull(1), which is used to request somebody to pull from a URL by sending an email. - git-filter-branch(1), which uses Perl with the `--state-branch` option. This command is typically recommended against nowadays in favor of git-filter-repo(1). - Our Perl bindings for Git. - The netrc Git credential helper. None of these subsystems can really be considered to be part of the "core" of Git, and an installation without them is fully functional. It is more likely than not that an end user wouldn't even notice that any features are missing if those tools weren't installed. But while Perl nowadays very much is an optional dependency of Git, there is a significant limitation when Perl isn't available: developers cannot run our test suite. Preceding commits have started to lift this restriction by removing the strict dependency on Perl in many central parts of the test library. But there are still many tests that rely on small Perl helpers to do various different things. Introduce a new PERL_TEST_HELPERS prerequisite that guards all tests that require Perl. This prerequisite is explicitly different than the preexisting PERL prerequisite: - PERL records whether or not features depending on the Perl interpreter are built. - PERL_TEST_HELPERS records whether or not a Perl interpreter is available for our tests. By having these two separate prerequisites we can thus distinguish between tests that inherently depend on Perl because the underlying feature does, and those tests that depend on Perl because the test itself is using Perl. Adapt all tests to set the PERL_TEST_HELPERS prerequisite as needed. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t: adapt `test_readlink()` to not use PerlPatrick Steinhardt2-1/+14
The `test_readlink()` helper function reads a symbolic link and returns the path it is pointing to. It is thus equivalent to the readlink(1) utility, which isn't available on all supported platforms. As such, it is implemented using Perl so that we can use it even on platforms where the shell utility isn't available. While using readlink(1) is not an option, what we can do is to implement the logic ourselves in our test-tool. Do so, which allows a bunch of tests to pass when Perl is not available. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t: adapt `test_copy_bytes()` to not use PerlPatrick Steinhardt1-11/+1
The `test_copy_bytes()` helper function copies up to N bytes from stdin to stdout. This is implemented using Perl, but it can be trivially adapted to instead use dd(1). Refactor the helper accordingly, which allows a bunch of tests to pass when Perl is not available. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t: adapt character translation helpers to not use PerlPatrick Steinhardt1-3/+3
We have a couple of helper functions that translate characters, e.g. from LF to NUL or NUL to 'Q' and vice versa. These helpers use Perl scripts, but they can be trivially adapted to instead use tr(1). Note that one specialty here is the handling of NUL characters in tr(1), which historically wasn't implemented correctly on all platforms. But quoting tr(1p): It was considered that automatically stripping NUL characters from the input was not correct functionality. However, the removal of -n in a later proposal does not remove the requirement that tr correctly process NUL characters in its input stream. So when tr(1) is implemented following the POSIX standard then it is expected to handle the transliteration of NUL just fine. Refactor the helpers accordingly, which allows a bunch of tests to pass when Perl is not available. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t: refactor environment sanitization to not use PerlPatrick Steinhardt1-18/+14
Before executing tests we first sanitize the environment. Part of the sanitization is to unset a couple of environment variables that we know will change the behaviour of Git. This is done with a small Perl script, which has the consequence that having a Perl interpreter available is a strict requirement for running our unit tests. The logic itself isn't particularly involved: we simply unset every environment variable whose key starts with 'GIT_', but then explicitly allow a subset of these. Refactor the logic to instead use sed(1) so that it becomes possible to execute our tests without Perl. Based-on-patch-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07t: skip chain lint when PERL_PATH is unsetPatrick Steinhardt1-0/+16
Our chainlint script verifies that test files have proper '&&' chains. This script is written in Perl and executed for every test file before executing the test logic itself. In subsequent commits we're about to refactor our test suite so that Perl becomes an optional dependency, only. And while it is already possible to disable this linter, developers that don't have Perl available at all would always have to disable the linter manually, which is rather cumbersome. Disable the chain linter automatically in case PERL_PATH isn't set to make this a bit less annoying. Bail out with an error in case the developer has asked explicitly for the chain linter. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07builtin/cat-file: use bitmaps to efficiently filter by object typePatrick Steinhardt1-5/+37
While it is now possible to filter objects by type, this mechanism is for now mostly a convenience. Most importantly, we still have to iterate through the whole packfile to find all objects of a specific type. This can be prohibitively expensive depending on the size of the packfiles. It isn't really possible to do better than this when only considering a packfile itself, as the order of objects is not fixed. But when we have a packfile with a corresponding bitmap, either because the packfile itself has one or because the multi-pack index has a bitmap for it, then we can use these bitmaps to improve the runtime. While bitmaps are typically used to compute reachability of objects, they also contain one bitmap per object type that encodes which object has what type. So instead of reading through the whole packfile(s), we can use the bitmaps and iterate through the type-specific bitmap. Typically, only a subset of packfiles will have a bitmap. But this isn't really much of a problem: we can use bitmaps when available, and then use the non-bitmap walk for every packfile that isn't covered by one. Overall, this leads to quite a significant speedup depending on how many objects of a certain type exist. The following benchmarks have been executed in the Chromium repository, which has a 50GB packfile with almost 25 million objects. As expected, there isn't really much of a change in performance without an object filter: Benchmark 1: cat-file with no-filter (revision = HEAD~) Time (mean ± σ): 89.675 s ± 4.527 s [User: 40.807 s, System: 10.782 s] Range (min … max): 83.052 s … 96.084 s 10 runs Benchmark 2: cat-file with no-filter (revision = HEAD) Time (mean ± σ): 88.991 s ± 2.488 s [User: 42.278 s, System: 10.305 s] Range (min … max): 82.843 s … 91.271 s 10 runs Summary cat-file with no-filter (revision = HEAD) ran 1.01 ± 0.06 times faster than cat-file with no-filter (revision = HEAD~) We still have to scan through all objects as we yield all of them, so using the bitmap in this case doesn't really buy us anything. What is noticeable in this benchmark is that we're I/O-bound, not CPU-bound, as can be seen from the user/system runtimes, which combined are way lower than the overall benchmarked runtime. But when we do use a filter we can see a significant improvement: Benchmark 1: cat-file with filter=object:type=commit (revision = HEAD~) Time (mean ± σ): 86.444 s ± 4.081 s [User: 36.830 s, System: 11.312 s] Range (min … max): 80.305 s … 93.104 s 10 runs Benchmark 2: cat-file with filter=object:type=commit (revision = HEAD) Time (mean ± σ): 2.089 s ± 0.015 s [User: 1.872 s, System: 0.207 s] Range (min … max): 2.073 s … 2.119 s 10 runs Summary cat-file with filter=object:type=commit (revision = HEAD) ran 41.38 ± 1.98 times faster than cat-file with filter=object:type=commit (revision = HEAD~) This is because we don't have to scan through all packfiles anymore, but can instead directly look up relevant objects. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07builtin/cat-file: deduplicate logic to iterate over all objectsPatrick Steinhardt1-37/+48
Pull out a common function that allows us to iterate over all objects in a repository. Right now the logic is trivial and would only require two function calls, making this refactoring a bit pointless. But in the next commit we will iterate on this logic to make use of bitmaps, so this is about to become a bit more complex. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07pack-bitmap: introduce function to check whether a pack is bitmappedPatrick Steinhardt2-0/+22
Introduce a function that allows us to verify whether a pack is bitmapped or not. This functionality will be used in a subsequent commit. Helped-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07pack-bitmap: add function to iterate over filtered bitmapped objectsPatrick Steinhardt2-6/+65
Introduce a function that allows the caller to iterate over all bitmapped objects that match a given filter. This mechanism will be used in a subsequent commit to optimize object filters in git-cat-file(1). Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07pack-bitmap: allow passing payloads to `show_reachable_fn()`Patrick Steinhardt5-11/+16
The `show_reachable_fn` callback is used by a couple of functions to present reachable objects to the caller. The function does not provide a way for the caller to pass a payload though, which is functionality that we'll require in a subsequent commit. Change the callback type to accept a payload and adapt all callsites accordingly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07builtin/cat-file: support "object:type=" objects filterPatrick Steinhardt3-2/+19
Implement support for the "object:type=" filter in git-cat-file(1), which causes us to omit all objects that don't match the provided object type. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07builtin/cat-file: support "blob:limit=" objects filterPatrick Steinhardt3-4/+34
Implement support for the "blob:limit=" filter in git-cat-file(1), which causes us to omit all blobs that are bigger than a certain size. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07builtin/cat-file: support "blob:none" objects filterPatrick Steinhardt3-4/+62
Implement support for the "blob:none" filter in git-cat-file(1), which causes us to omit all blobs. Note that this new filter requires us to read the object type via `oid_object_info_extended()` in `batch_object_write()`. But as we try to optimize away reading objects from the database the `data->info.typep` pointer may not be set. We thus have to adapt the logic to conditionally set the pointer in cases where the filter is given. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07builtin/cat-file: wire up an option to filter objectsPatrick Steinhardt3-4/+88
In batch mode, git-cat-file(1) enumerates all objects and prints them by iterating through both loose and packed objects. This works without considering their reachability at all, and consequently most options to filter objects as they exist in e.g. git-rev-list(1) are not applicable. In some situations it may still be useful though to filter objects based on properties that are inherent to them. This includes the object size as well as its type. Such a filter already exists in git-rev-list(1) with the `--filter=` command line option. While this option supports a couple of filters that are not applicable to our usecase, some of them are quite a neat fit. Wire up the filter as an option for git-cat-file(1). This allows us to reuse the same syntax as in git-rev-list(1) so that we don't have to reinvent the wheel. For now, we die when any of the filter options has been passed by the user, but they will be wired up in subsequent commits. Further note that the filters that we are about to introduce don't significantly speed up the runtime of git-cat-file(1). While we can skip emitting a lot of objects in case they are uninteresting to us, the majority of time is spent reading the packfile, which is bottlenecked by I/O and not the processor. This will change though once we start to make use of bitmaps, which will allow us to skip reading the whole packfile. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07builtin/cat-file: introduce function to report object statusPatrick Steinhardt1-5/+13
We have multiple callsites that report the status of an object, for example when the objec tis missing or its name is ambiguous. We're about to add a couple more such callsites to report on "excluded" objects. Prepare for this by introducing a new function `report_object_status()` that encapsulates the functionality. Note that this function also flushes stdout, which is a requirement so that request-response style batched modes can learn about the status before proceeding to the next object. We already flush correctly at all existing callsites, even though the flush in `batch_one_object()` only comes after the switch statement. That flush is now redundant, and we could in theory deduplicate it by moving it into all branches that don't use `report_object_status()`. But that doesn't quite feel sensible: - The duplicate flush should ultimately just be a no-op for us and thus shouldn't impact performance significantly. - By keeping the flush in `report_object_status()` we ensure that all future callers get semantics correct. So let's just be pragmatic and live with the duplicated flush. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07builtin/cat-file: rename variable that tracks usagePatrick Steinhardt1-22/+25
The usage strings for git-cat-file(1) that we pass to `parse_options()` and `usage_msg_optf()` are stored in a variable called `usage`. This variable shadows the declaration of `usage()`, which we'll want to use in a subsequent commit. Rename the variable to `builtin_catfile_usage`, which is in line with how the variable is typically called in other builtins. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07help: include unsafe SHA-1 build info in versionJustin Tobler3-1/+10
In 06c92dafb8 (Makefile: allow specifying a SHA-1 for non-cryptographic uses, 2024-09-26), support for unsafe SHA-1 is added. Add the unsafe SHA-1 build info to `git version --build-info` and update corresponding documentation. Signed-off-by: Justin Tobler <jltobler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07help: include SHA implementation in version infoJustin Tobler3-0/+17
When the `--build-options` flag is used with git-version(1), additional information about the built version of Git is printed. During build time, different SHA implementations may be configured, but this information is not included in the version info. Add the SHA implementations Git is built with to the version info by requiring each backend to define a SHA1_BACKEND or SHA256_BACKEND symbol as appropriate and use the value in the printed build options. Signed-off-by: Justin Tobler <jltobler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07The third batchJunio C Hamano1-0/+35
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2025-04-07Merge branch 'js/imap-send-peer-cert-verify'Junio C Hamano1-0/+2
* js/imap-send-peer-cert-verify: imap-send: explicitly verify the peer certificate
2025-04-07Merge branch 'js/mingw-admins-are-special'Junio C Hamano2-11/+47
"Dubious ownership" checks on Windows has been tightened up. * js/mingw-admins-are-special: test-tool path-utils: support debugging "dubious ownership" issues mingw: special-case administrators even more
2025-04-07Merge branch 'tb/bitamp-typofix'Junio C Hamano1-1/+1
Typofix. * tb/bitamp-typofix: pseudo-merge.h: fix a typo
2025-04-07Merge branch 'dm/completion-remote-names-fix'Junio C Hamano2-29/+226
The bash command line completion script (in contrib/) has been updated to cope with remote repository nicknames with slashes in them. * dm/completion-remote-names-fix: completion: fix bugs with slashes in remote names completion: add helper to count path components
2025-04-07Merge branch 'pw/doc-pack-refs-markup-fix'Junio C Hamano1-2/+2
Doc markup fix. * pw/doc-pack-refs-markup-fix: pack-refs doc: fix indentation for --exclude
2025-04-07Merge branch 'pw/build-breaking-changes-doc'Junio C Hamano2-0/+2
A documentation page was left out from formatting and installation, which has been corrected. * pw/build-breaking-changes-doc: docs: add BreakingChanges to TECH_DOCS target
2025-04-07Merge branch 'ja/doc-branch-markup'Junio C Hamano3-200/+208
Doc mark-up updates. * ja/doc-branch-markup: doc: apply new format to git-branch man page completion: take into account the formatting backticks for options
2025-04-07Merge branch 'jh/hash-init-fixes'Junio C Hamano2-0/+2
An earlier code refactoring of the hash machinery missed a few required calls to init_fn. * jh/hash-init-fixes: index-pack, unpack-objects: restore missing ->init_fn
2025-04-07Merge branch 'tb/combine-cruft-below-size'Junio C Hamano4-323/+355
"git repack" learned "--combine-cruft-below-size" option that controls how cruft-packs are combined. * tb/combine-cruft-below-size: repack: begin combining cruft packs with `--combine-cruft-below-size` repack: avoid combining cruft packs with `--max-cruft-size` t/t7704-repack-cruft.sh: consolidate `write_blob()` t/t7704-repack-cruft.sh: clarify wording in --max-cruft-size tests t/t5329-pack-objects-cruft.sh: evict 'repack'-related tests
2025-04-07Merge branch 'cc/lop-remote'Junio C Hamano3-20/+86
Bugfix in newly introduced large-object-promisor remote support. * cc/lop-remote: promisor-remote: compare remote names case sensitively promisor-remote: fix possible issue when no URL is advertised promisor-remote: fix segfault when remote URL is missing t5710: arrange to delete the client before cloning
2025-04-07Merge branch 'jc/name-rev-stdin'Junio C Hamano10-17/+72
Using "git name-rev --stdin" as an example, improve the framework to prepare tests to pretend to be in the future where the breaking changes have already happened. * jc/name-rev-stdin: name-rev: remove "--stdin" support t6120: further modernize t6120: avoid hiding "git" exit status t: introduce WITH_BREAKING_CHANGES prerequisite t: extend test_lazy_prereq t: document test_lazy_prereq