aboutsummaryrefslogtreecommitdiffstats
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2024-09-30Merge branch 'ps/reftable-concurrent-writes'Junio C Hamano2-2/+123
Give timeout to the locking code to write to reftable. * ps/reftable-concurrent-writes: refs/reftable: reload locked stack when preparing transaction reftable/stack: allow locking of outdated stacks refs/reftable: introduce "reftable.lockTimeout"
2024-09-25Merge branch 'rs/diff-exit-code-binary'Junio C Hamano1-0/+8
"git diff --exit-code" ignored modified binary files, which has been corrected. * rs/diff-exit-code-binary: diff: report modified binary files as changes in builtin_diff()
2024-09-25Merge branch 'ps/reftable-exclude'Junio C Hamano8-188/+397
The reftable backend learned to more efficiently handle exclude patterns while enumerating the refs. * ps/reftable-exclude: refs/reftable: wire up support for exclude patterns reftable/reader: make table iterator reseekable t/unit-tests: introduce reftable library Makefile: stop listing test library objects twice builtin/receive-pack: fix exclude patterns when announcing refs refs: properly apply exclude patterns to namespaced refs
2024-09-25Merge branch 'ps/apply-leakfix'Junio C Hamano5-2/+6
"git apply" had custom buffer management code that predated before use of strbuf got widespread, which has been updated to use strbuf, which also plugged some memory leaks. * ps/apply-leakfix: apply: refactor `struct image` to use a `struct strbuf` apply: rename members that track line count and allocation length apply: refactor code to drop `line_allocated` apply: introduce macro and function to init images apply: rename functions operating on `struct image` apply: reorder functions to move image-related things together
2024-09-24refs/reftable: reload locked stack when preparing transactionPatrick Steinhardt1-0/+31
When starting a reftable transaction we lock all stacks we are about to modify. While it may happen that the stack is out-of-date at this point in time we don't really care: transactional updates encode the expected state of a certain reference, so all that we really want to verify is that the _current_ value matches that expected state. Pass `REFTABLE_STACK_NEW_ADDITION_RELOAD` when locking the stack such that an out-of-date stack will be reloaded after having been locked. This change is safe because all verifications of the expected state happen after this step anyway. Add a testcase that verifies that many writers are now able to write to the stack concurrently without failures and with a deterministic end result. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-24reftable/stack: allow locking of outdated stacksPatrick Steinhardt1-2/+65
In `reftable_stack_new_addition()` we first lock the stack and then check whether it is still up-to-date. If it is not we return an error to the caller indicating that the stack is outdated. This is overly restrictive in our ref transaction interface though: we lock the stack right before we start to verify the transaction, so we do not really care whether it is outdated or not. What we really want is that the stack is up-to-date after it has been locked so that we can verify queued updates against its current state while we know that it is locked for concurrent modification. Introduce a new flag `REFTABLE_STACK_NEW_ADDITION_RELOAD` that alters the behaviour of `reftable_stack_init_addition()` in this case: when we notice that it is out-of-date we reload it instead of returning an error to the caller. This logic will be wired up in the reftable backend in the next commit. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-24refs/reftable: introduce "reftable.lockTimeout"Patrick Steinhardt1-0/+27
When multiple concurrent processes try to update references in a repository they may try to lock the same lockfiles. This can happen even when the updates are non-conflicting and can both be applied, so it doesn't always make sense to abort the transaction immediately. Both the "loose" and "packed" backends thus have a grace period that they wait for the lock to be released that can be controlled via the config values "core.filesRefLockTimeout" and "core.packedRefsTimeout", respectively. The reftable backend doesn't have such a setting yet and instead fails immediately when it sees such a lock. But the exact same concepts apply here as they do apply to the other backends. Introduce a new "reftable.lockTimeout" config that controls how long we may wait for a "tables.list" lock to be released. The default value of this config is 100ms, which is the same default as we have it for the "loose" backend. Note that even though we also lock individual tables, this config really only applies to the "tables.list" file. This is because individual tables are only ever locked when we already hold the "tables.list" lock during compaction. When we observe such a lock we in fact do not want to compact the table at all because it is already in the process of being compacted by a concurrent process. So applying the same timeout here would not make any sense and only delay progress. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-23Merge branch 'jk/t9001-deflake'Junio C Hamano1-2/+2
Test fix. * jk/t9001-deflake: t9001: use a more distinct fake BugID
2024-09-23Merge branch 'jk/diag-unexpected-remote-helper-death'Junio C Hamano1-0/+11
When a remote-helper dies before Git writes to it, SIGPIPE killed Git silently. We now explain the situation a bit better to the end user in our error message. * jk/diag-unexpected-remote-helper-death: print an error when remote helpers die during capabilities
2024-09-23Merge branch 'jc/t5512-sigpipe-fix'Junio C Hamano1-0/+1
Test fix. * jc/t5512-sigpipe-fix: t5512.40 sometimes dies by SIGPIPE
2024-09-23Merge branch 'ps/environ-wo-the-repository'Junio C Hamano2-1/+4
Code clean-up. * ps/environ-wo-the-repository: (21 commits) environment: stop storing "core.notesRef" globally environment: stop storing "core.warnAmbiguousRefs" globally environment: stop storing "core.preferSymlinkRefs" globally environment: stop storing "core.logAllRefUpdates" globally refs: stop modifying global `log_all_ref_updates` variable branch: stop modifying `log_all_ref_updates` variable repo-settings: track defaults close to `struct repo_settings` repo-settings: split out declarations into a standalone header environment: guard state depending on a repository environment: reorder header to split out `the_repository`-free section environment: move `set_git_dir()` and related into setup layer environment: make `get_git_namespace()` self-contained environment: move object database functions into object layer config: make dependency on repo in `read_early_config()` explicit config: document `read_early_config()` and `read_very_early_config()` environment: make `get_git_work_tree()` accept a repository environment: make `get_graft_file()` accept a repository environment: make `get_index_file()` accept a repository environment: make `get_object_directory()` accept a repository environment: make `get_git_common_dir()` accept a repository ...
2024-09-23diff: report modified binary files as changes in builtin_diff()René Scharfe1-0/+8
The diff machinery has two ways to detect changes to set the exit code: Just comparing hashes and comparing blob contents. The latter is needed if certain changes have to be ignored, e.g. with --ignore-space-change or --ignore-matching-lines. It's enabled by the diff_options flag diff_from_contents. The code for handling binary files added by 1aaf69e669 (diff: shortcut for diff'ing two binary SHA-1 objects, 2014-08-16) always uses a quick hash-only comparison, even if the slow way is taken. We need it to report a hash difference as a change for the purpose of setting the exit code, though, but it never did. Fix that. d7b97b7185 (diff: let external diffs report that changes are uninteresting, 2024-06-09) set diff_from_contents if external diff programs are allowed. This is the default e.g. for git diff, and so that change exposed the inconsistency much more widely. Reported-by: Kohei Shibata <shiba200712@gmail.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-20Merge branch 'jk/git-pm-bare-repo-fix'Junio C Hamano2-1/+7
In Git 2.39, Git.pm stopped working in a bare repository, which has been corrected. * jk/git-pm-bare-repo-fix: Git.pm: use "rev-parse --absolute-git-dir" rather than perl code Git.pm: fix bare repository search with Directory option
2024-09-20Merge branch 'ma/test-libcurl-prereq'Junio C Hamano2-3/+5
Test portability fix. * ma/test-libcurl-prereq: t0211: add missing LIBCURL prereq t1517: add missing LIBCURL prereq
2024-09-20Merge branch 'jk/interop-test-build-options'Junio C Hamano3-3/+13
The support to customize build options to adjust for older versions and/or older systems for the interop tests has been improved. * jk/interop-test-build-options: t/interop: allow per-version make options
2024-09-20Merge branch 'ps/leakfixes-part-6'Junio C Hamano19-1/+32
More leakfixes. * ps/leakfixes-part-6: (22 commits) builtin/repack: fix leaking keep-pack list merge-ort: fix two leaks when handling directory rename modifications match-trees: fix leaking prefixes in `shift_tree()` builtin/fmt-merge-msg: fix leaking buffers builtin/grep: fix leaking object context builtin/pack-objects: plug leaking list of keep-packs builtin/repack: fix leaking line buffer when packing promisors negotiator/skipping: fix leaking commit entries shallow: fix leaking members of `struct shallow_info` shallow: free grafts when unregistering them object: clear grafts when clearing parsed object pool gpg-interface: fix misdesigned signing key interfaces send-pack: fix leaking push cert nonce remote: fix leak in reachability check of a remote-tracking ref remote: fix leaking tracking refs builtin/submodule--helper: fix leaking refs on push-check submodule: fix leaking fetch task data upload-pack: fix leaking child process data on reachability checks builtin/push: fix leaking refspec query result send-pack: fix leaking common object IDs ...
2024-09-20Merge branch 'pw/rebase-autostash-fix'Junio C Hamano3-3/+49
"git rebase --autostash" failed to resurrect the autostashed changes when the command gets aborted after giving back control asking for hlep in conflict resolution. * pw/rebase-autostash-fix: rebase: apply and cleanup autostash when rebase fails to start
2024-09-18Merge branch 'es/chainlint-message-updates'Junio C Hamano45-95/+113
The error messages from the test script checker have been improved. * es/chainlint-message-updates: chainlint: reduce annotation noise-factor chainlint: make error messages self-explanatory chainlint: don't be fooled by "?!...?!" in test body
2024-09-18Merge branch 'ps/clar-unit-test'Junio C Hamano27-223/+3361
Import clar unit tests framework libgit2 folks invented for our use. * ps/clar-unit-test: Makefile: rename clar-related variables to avoid confusion clar: add CMake support t/unit-tests: convert ctype tests to use clar t/unit-tests: convert strvec tests to use clar t/unit-tests: implement test driver Makefile: wire up the clar unit testing framework Makefile: do not use sparse on third-party sources Makefile: make hdr-check depend on generated headers Makefile: fix sparse dependency on GENERATED_H clar: stop including `shellapi.h` unnecessarily clar(win32): avoid compile error due to unused `fs_copy()` clar: avoid compile error with mingw-w64 t/clar: fix compatibility with NonStop t: import the clar unit testing framework t: do not pass GIT_TEST_OPTS to unit tests with prove
2024-09-17apply: refactor `struct image` to use a `struct strbuf`Patrick Steinhardt5-2/+6
The `struct image` uses a character array to track the pre- or postimage of a patch operation. This has multiple downsides: - It is somewhat hard to track memory ownership. In fact, we have several memory leaks in git-apply(1) because we do not (and cannot easily) free the buffer in all situations. - We have to reinvent the wheel and manually implement a lot of functionality that would already be provided by `struct strbuf`. - We have to carefully track whether `update_pre_post_images()` can do an in-place update of the postimage or whether it has to allocate a new buffer for it. This is all rather cumbersome, and especially `update_pre_post_images()` is really hard to understand as a consequence even though what it is doing is rather trivial. Refactor the code to use a `struct strbuf` instead, addressing all of the above. Like this we can easily perform in-place updates in all situations, the logic to perform those updates becomes way simpler and the lifetime of the buffer becomes a ton easier to track. This refactoring also plugs some leaking buffers as a side effect. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-16Sync with 'maint'Junio C Hamano1-40/+0
2024-09-16Revert "Merge branch 'jc/patch-id' into maint-2.46"Junio C Hamano1-40/+0
This reverts commit 41c952ebacf7e3369e7bee721f768114d65e50c4, reversing changes made to 712d970c0145b95ce655773e7cd1676f09dfd215. Keeping a known breakage for now is better than introducing new regression(s).
2024-09-16Merge branch 'jk/ref-filter-trailer-fixes'Junio C Hamano2-2/+40
Bugfixes and leak plugging in "git for-each-ref --format=..." code paths. * jk/ref-filter-trailer-fixes: ref-filter: fix leak with unterminated %(if) atoms ref-filter: add ref_format_clear() function ref-filter: fix leak when formatting %(push:remoteref) ref-filter: fix leak with %(describe) arguments ref-filter: fix leak of %(trailers) "argbuf" ref-filter: store ref_trailer_buf data per-atom ref-filter: drop useless cast in trailers_atom_parser() ref-filter: strip signature when parsing tag trailers ref-filter: avoid extra copies of payload/signature t6300: drop newline from wrapped test title
2024-09-16Merge branch 'ah/apply-3way-ours'Junio C Hamano1-0/+40
"git apply --3way" learned to take "--ours" and other options. * ah/apply-3way-ours: apply: support --ours, --theirs, and --union for three-way merges
2024-09-16Merge branch 'cp/unit-test-reftable-stack'Junio C Hamano5-27/+1325
Another reftable test migrated to the unit-test framework. * cp/unit-test-reftable-stack: t-reftable-stack: add test for stack iterators t-reftable-stack: add test for non-default compaction factor t-reftable-stack: use reftable_ref_record_equal() to compare ref records t-reftable-stack: use Git's tempfile API instead of mkstemp() t: harmonize t-reftable-stack.c with coding guidelines t: move reftable/stack_test.c to the unit testing framework
2024-09-16refs/reftable: wire up support for exclude patternsPatrick Steinhardt1-9/+40
Exclude patterns can be used by reference backends to skip over blocks of references that are uninteresting to the caller. Reference backends do not have to wire up support for them, and all callers are expected to behave as if the backend didn't support them. In fact, the only backend that supports exclude patterns right now is the "packed" backend. Exclude patterns can be quite an important performance optimization in repositories that have loads of references. The patterns are set up in case "transfer.hideRefs" and friends are configured during a fetch, so handling these patterns becomes important once there are lots of hidden refs in a served repository. Now that we have properly re-seekable reftable iterators we can also wire up support for these patterns in the "reftable" backend. Doing so is conceptually simple: once we hit a reference whose prefix matches the current exclude pattern we re-seek the iterator to the first reference that doesn't match the pattern anymore. This schema only works for trivial patterns that do not have any globbing characters in them, but this restriction also applies do the "packed" backend. This makes t1419 work with the "reftable" backend with some slight modifications. Of course it also speeds up listing of references with hidden refs. The following benchmark prints one reference with 1 million hidden references: Benchmark 1: HEAD~ Time (mean ± σ): 93.3 ms ± 2.1 ms [User: 90.3 ms, System: 2.5 ms] Range (min … max): 89.8 ms … 97.2 ms 33 runs Benchmark 2: HEAD Time (mean ± σ): 4.2 ms ± 0.6 ms [User: 2.2 ms, System: 1.8 ms] Range (min … max): 3.1 ms … 8.1 ms 765 runs Summary HEAD ran 22.15 ± 3.19 times faster than HEAD~ Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-16reftable/reader: make table iterator reseekablePatrick Steinhardt2-0/+172
In 67ce50ba26 (Merge branch 'ps/reftable-reusable-iterator', 2024-05-30) we have refactored the interface of reftable iterators such that they can be reused in theory. This patch series only landed the required changes on the interface level, but didn't yet implement the actual logic to make iterators reusable. As it turns out almost all of the infrastructure already does support re-seeking. The only exception is the table iterator, which does not reset its `is_finished` bit. Do so and add a couple of tests that verify that we can re-seek iterators. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-16t/unit-tests: introduce reftable libraryPatrick Steinhardt5-179/+176
We have recently migrated all of the reftable unit tests that were part of the reftable library into our own unit testing framework. As part of that migration we have duplicated some of the functionality that was part of the reftable test framework into each of the migrated test suites. This was a sensible decision to not have all of the migrations dependent on each other, but now that the migration is done it makes sense to deduplicate the functionality again. Introduce a new reftable test library that hosts some shared code and adapt tests to use it. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-16builtin/receive-pack: fix exclude patterns when announcing refsPatrick Steinhardt1-0/+8
In `write_head_info()` we announce references to the remote client. We need to honor "transfer.hideRefs" here so that we do not announce any references that the client shouldn't be able to learn about. This is done via two separate mechanisms: - We hand over exclude patterns to the reference backend. We can only honor "plain" exclude patterns here that do not have prefixes with special meaning such as "^" or "!". Filtering down the references is handled by `hidden_refs_to_excludes()`. - In `show_ref_cb()` we perform a second check against hidden refs. For one this is done such that we can handle those special prefixes. And second, handling exclude patterns in ref backends is optional, so we also have to handle "normal" patterns. The special-meaning "^" prefix alters whether a hidden ref applies to the namespace-stripped reference name or the full name. So while we would usually call `refs_for_each_namespaced_ref()` to only get those references in the current namespace, we can't because we'd get the already-rewritten reference names. Instead, we are forced to use `refs_for_each_fullref_in()` and then manually strip away the namespace prefix such that we have access to both names. But this also means that we do not get namespace handling for exclude patterns, which `refs_for_each_namespaced_ref()` brings for free. This results in a bug because we potentially end up hiding away references based on their namespaced name and not on the stripped name as we really should be doing. Fix this by manually rewriting the exclude patterns to their namespaced variants. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-16refs: properly apply exclude patterns to namespaced refsPatrick Steinhardt1-0/+1
Reference namespaces allow commands like git-upload-pack(1) to serve different sets of references to the client depending on which namespace is enabled, which is for example useful in fork networks. Namespaced refs are stored with a `refs/namespaces/$namespace` prefix, but all the user will ultimately see is a stripped version where that prefix is removed. The way that this interacts with "transfer.hideRefs" is not immediately obvious: the hidden refs can either apply to the stripped references, or to the non-stripped ones that still have the namespace prefix. In fact, the "transfer.hideRefs" machinery does the former and applies to the stripped reference by default, but rules can have "^" prefixed to switch this behaviour to instead match against the full reference name. Namespaces are exclusively handled at the generic "refs" layer, the respective backends have no clue that such a thing even exists. This also has the consequence that they cannot handle hiding references as soon as reference namespaces come into play because they neither know whether a namespace is active, nor do they know how to strip references if they are active. Handling such exclude patterns in `refs_for_each_namespaced_ref()` and `refs_for_each_fullref_in_prefixes()` is broken though, as both support that the user passes both namespaces and exclude patterns. In the case where both are set we will exclude references with unstripped names, even though we really wanted to exclude references based on their stripped names. This only surfaces when: - A repository uses reference namespaces. - "transfer.hideRefs" is active. - The namespaced references are packed into the "packed-refs" file. None of our tests exercise this scenario, and thus we haven't ever hit it. While t5509 exercises both (1) and (2), it does not happen to hit (3). It is trivial to demonstrate the bug though by explicitly packing refs in the tests, and then we indeed surface the breakage. Fix this bug by prefixing exclude patterns with the namespace in the generic layer. The newly introduced function will be used outside of "refs.c" in the next patch, so we add a declaration to "refs.h". Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-16t9001: use a more distinct fake BugIDJeff King1-2/+2
In the test "cc list is sanitized", we feed a commit with a variety of trailers to send-email, and then check its output to see how it handled them. For most of them, we are grepping for a specific mention of the header, but there's a "BugID" header which we expect to be ignored. We confirm this by grepping for "12345", the fake BugID, and making sure it is not present. But we can be fooled by false positives! I just tracked down a flaky test failure here that was caused by matching this unrelated line in the output: <20240914090449.612345-1-author@example.com> which will change from run to run based on the time, pid, etc. Ideally we'd tighten the regex to make this more specifically, but since the point is that it _shouldn't_ be mentioned, it's hard to say what the right match would be (e.g., would there be a leading space?). Instead, let's just choose a match that is much less likely to appear. The actual content of the header isn't important, since it's supposed to be ignored. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-14print an error when remote helpers die during capabilitiesJeff King1-0/+11
The transport-helper code generally relies on the remote-helper to provide an informative message to the user when it encounters an error. In the rare cases where the helper does not do so, the output can be quite confusing. E.g.: $ git clone https://example.com/foo.git Cloning into 'foo'... $ echo $? 128 $ ls foo /bin/ls: cannot access foo: No such file or directory We tried to address this with 81d340d (transport-helper: report errors properly, 2013-04-10). But that makes the common case much more confusing. The remote helper protocol's method for signaling normal errors is to simply hang up. So when the helper does encounter a routine error and prints something to stderr, the extra error message is redundant and misleading. So we dropped it again in 266f1fd (transport-helper: be quiet on read errors from helpers, 2013-06-21). This puts the uncommon case right back where it started. We may be able to do a little better, though. It is common for the helper to die during a "real" command, like fetching the list of remote refs. It is not common for it to die during the initial "capabilities" negotiation, right after we start. Reporting failure here is likely to catch fundamental problems that prevent the helper from running (and reporting errors) at all. Anything after that is the responsibility of the helper itself to report. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-13Merge branch 'bl/trailers-and-incomplete-last-line-fix'Junio C Hamano1-0/+40
The interpret-trailers command failed to recognise the end of the message when the commit log ends in an incomplete line. * bl/trailers-and-incomplete-last-line-fix: interpret-trailers: handle message without trailing newline
2024-09-13Merge branch 'rs/diff-exit-code-fix'Junio C Hamano1-0/+37
In a few corner cases "git diff --exit-code" failed to report "changes" (e.g., renamed without any content change), which has been corrected. * rs/diff-exit-code-fix: diff: report dirty submodules as changes in builtin_diff() diff: report copies and renames as changes in run_diff_cmd()
2024-09-13Merge branch 'ds/scalar-no-tags'Junio C Hamano1-0/+18
The "scalar clone" command learned the "--no-tags" option. * ds/scalar-no-tags: scalar: add --no-tags option to 'scalar clone'
2024-09-13Merge branch 'ps/stash-keep-untrack-empty-fix' into maint-2.46Junio C Hamano1-0/+15
A corner case bug in "git stash" was fixed. * ps/stash-keep-untrack-empty-fix: builtin/stash: fix `--keep-index --include-untracked` with empty HEAD
2024-09-13Merge branch 'ps/index-pack-outside-repo-fix' into maint-2.46Junio C Hamano1-0/+39
"git verify-pack" and "git index-pack" started dying outside a repository, which has been corrected. * ps/index-pack-outside-repo-fix: builtin/index-pack: fix segfaults when running outside of a repo
2024-09-13t5512.40 sometimes dies by SIGPIPEJunio C Hamano1-0/+1
The last test in t5512 we recently added seems to be flaky. Running $ make && cd t && sh ./t5512-ls-remote.sh --stress shows that "git ls-remote foo::bar" exited with status 141, which means we got a SIGPIPE. This test piece was introduced by 9e89dcb6 (builtin/ls-remote: fall back to SHA1 outside of a repo, 2024-08-02) and is pretty much independent from all other tests in the script (it can even run standalone with everything before it removed). The transport-helper.c:get_helper() function tries to write to the helper. As we can see the helper script is very short and can exit even before it reads anything, when get_helper() tries to give the first command, "capabilities", the helper may already be gone. A trivial fix, presented here, is to make sure that the helper reads the first command it is given, as what it writes later is a response to that command. I however would wonder if the interactions with the helper initiated by get_helper() should be done on a non-blocking I/O (we do check the return value from our write(2) system calls, do we?). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-13Git.pm: fix bare repository search with Directory optionJeff King2-1/+7
When opening a bare repository like: Git->repository(Directory => '/path/to/bare.git'); we will incorrectly point the repository object at the _current_ directory, not the one specified by the option. The bug was introduced by 20da61f25f (Git.pm: trust rev-parse to find bare repositories, 2022-10-22). Before then, we'd ask "rev-parse --git-dir" if it was a Git repo, and if it returned anything, we'd correctly convert that result to an absolute path using File::Spec and Cwd::abs_path(). If it didn't, we'd guess it might be a bare repository and find it ourselves, which was wrong (rev-parse should find even a bare repo, and our search circumvented some of its rules). That commit dropped most of the custom bare-repo search code in favor of using "rev-parse --is-bare-repository" and trusting the "--git-dir" it returned. But it mistakenly left some of the bare-repo code path in place, which was now broken. That code calls Cwd::abs_path($dir); prior to 20da61f25f $dir contained the "Directory" option the user passed in. But afterwards, it contains the output of "rev-parse --git-dir". And since our tentative rev-parse command is invoked after changing directory, it will always be the relative path "."! So we'll end up with the absolute path of the process's current directory, not the Directory option the caller asked for. So the non-bare case is correct, but the bare one is broken. Our tests only check the non-bare one, so we didn't notice. We can fix this by running the same absolute-path fixup code for both sides. Helped-by: Rodrigo <rodrigolive@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-12t/interop: allow per-version make optionsJeff King3-3/+13
Building older versions of Git may require tweaking some build knobs. In particular, very old versions of Git will fail to build with recent OpenSSL, because the bignum type switched from a struct to a pointer. The i5500 interop test uses Git v1.0.0 by default, which triggers this problem. You can work around it by setting NO_OPENSSL in your GIT_TEST_MAKE_OPTS variable. But there are two downsides: 1. You have to know to do this, and it's not at all obvious. 2. That sets the options for _all_ versions of Git that we build. And it's possible for two versions to require conflicting knobs. E.g., building with "make NO_OPENSSL=Nope OPENSSL_SHA1=Yes" causes imap-send.c to barf, because it declares a fallback typedef for SSL. This is something we may want to fix, but of course many historical versions are affected, and the interop scripts should be flexible enough to build everything. So let's introduce per-version make options, along with the ability for scripts to specify knobs that match their default versions. That should make everything build out of the box, but also allow testers flexibility if they are testing interoperability between non-default versions. We'll set NO_OPENSSL by default for v1.0.0 in i5500. It doesn't have to worry about the conflict with OPENSSL_SHA1 because imap-send did not exist back then (but if it did, it could also just explicitly use a different hash implementation). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-12Merge branch 'kl/cat-file-on-sparse-index'Junio C Hamano1-5/+45
"git cat-file" works well with the sparse-index, and gets marked as such. * kl/cat-file-on-sparse-index: builtin/cat-file: mark 'git cat-file' sparse-index compatible t1092: allow run_on_* functions to use standard input
2024-09-12Merge branch 'jk/messages-with-excess-lf-fix'Junio C Hamano3-10/+10
One-line messages to "die" and other helper functions will get LF added by these helper functions, but many existing messages had an unnecessary LF at the end, which have been corrected. * jk/messages-with-excess-lf-fix: drop trailing newline from warning/error/die messages
2024-09-12Merge branch 'ps/pack-refs-auto-heuristics'Junio C Hamano1-16/+85
"git pack-refs --auto" for the files backend was too aggressive, which has been a bit tamed. * ps/pack-refs-auto-heuristics: refs/files: use heuristic to decide whether to repack with `--auto` t0601: merge tests for auto-packing of refs wrapper: introduce `log2u()`
2024-09-12Merge branch 'tb/multi-pack-reuse-fix'Junio C Hamano1-4/+31
A data corruption bug when multi-pack-index is used and the same objects are stored in multiple packfiles has been corrected. * tb/multi-pack-reuse-fix: builtin/pack-objects.c: do not open-code `MAX_PACK_OBJECT_HEADER` pack-bitmap.c: avoid repeated `pack_pos_to_offset()` during reuse builtin/pack-objects.c: translate bit positions during pack-reuse pack-bitmap: tag bitmapped packs with their corresponding MIDX t/t5332-multi-pack-reuse.sh: verify pack generation with --strict
2024-09-12Merge branch 'gt/unit-test-oid-array'Junio C Hamano7-174/+135
Another unit-test. * gt/unit-test-oid-array: t: port helper/test-oid-array.c to unit-tests/t-oid-array.c
2024-09-12Merge branch 'ps/index-pack-outside-repo-fix'Junio C Hamano1-0/+39
"git verify-pack" and "git index-pack" started dying outside a repository, which has been corrected. * ps/index-pack-outside-repo-fix: builtin/index-pack: fix segfaults when running outside of a repo
2024-09-12Merge branch 'jc/tests-no-useless-tee' into maint-2.46Junio C Hamano2-3/+3
Test fixes. * jc/tests-no-useless-tee: tests: drop use of 'tee' that hides exit status
2024-09-12Merge branch 'ps/bundle-outside-repo-fix' into maint-2.46Junio C Hamano1-0/+32
"git bundle unbundle" outside a repository triggered a BUG() unnecessarily, which has been corrected. * ps/bundle-outside-repo-fix: bundle: default to SHA1 when reading bundle headers builtin/bundle: have unbundle check for repo before opening its bundle
2024-09-12Merge branch 'jc/patch-id' into maint-2.46Junio C Hamano1-0/+40
The patch parser in "git patch-id" has been tightened to avoid getting confused by lines that look like a patch header in the log message. cf. <Zqh2T_2RLt0SeKF7@tanuki> * jc/patch-id: patch-id: tighten code to detect the patch header patch-id: rewrite code that detects the beginning of a patch patch-id: make get_one_patchid() more extensible patch-id: call flush_current_id() only when needed t4204: patch-id supports various input format
2024-09-12Merge branch 'jk/apply-patch-mode-check-fix' into maint-2.46Junio C Hamano1-0/+62
Test fix. * jk/apply-patch-mode-check-fix: t4129: fix racy index when calling chmod after git-add apply: canonicalize modes read from patches
2024-09-12environment: guard state depending on a repositoryPatrick Steinhardt1-0/+2
In "environment.h" we have quite a lot of functions and variables that either explicitly or implicitly depend on `the_repository`. The implicit set of stateful declarations includes for example variables which get populated when parsing a repository's Git configuration. This set of variables is broken by design, as their state often depends on the last repository config that has been parsed. So they may or may not represent the state of `the_repository`. Fixing that is quite a big undertaking, and later patches in this series will demonstrate a solution for a first small set of those variables. So for now, let's guard these with `USE_THE_REPOSITORY_VARIABLE` so that callers are aware of the implicit dependency. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-12config: make dependency on repo in `read_early_config()` explicitPatrick Steinhardt1-1/+2
The `read_early_config()` function can be used to read configuration where a repository has not yet been set up. As such, it is optional whether or not `the_repository` has already been initialized. If it was initialized we use its commondir and gitdir. If not, the function will try to detect the Git directories by itself and, if found, also parse their config files. This means that we implicitly rely on `the_repository`. Make this dependency explicit by passing a `struct repository`. This allows us to again drop the `USE_THE_REPOSITORY_VARIABLE` define in "config.c". Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-11t0211: add missing LIBCURL prereqMartin Ågren1-2/+4
After building Git with NO_LIBCURL, we're lacking `git remote-http` and `git http-fetch`, so when we test that they trace as they should, we're bound to fail. Add the LIBCURL prereq to those tests. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-11t1517: add missing LIBCURL prereqMartin Ågren1-1/+1
After building Git with NO_LIBCURL, there is no `git remote-http`, so it's not meaningful to test that it can run outside of a repository. Indeed, that test will fail. Add the LIBCURL prereq to it. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-10chainlint: reduce annotation noise-factorEric Sunshine2-2/+3
When chainlint detects a problem in a test definition, it highlights the offending code with a "?!...?!" annotation. The rather curious "?!" decoration was chosen to draw the reader's attention to the problem area and to act as a good "needle" when using the terminal's search feature to "jump" to the next problem. Later, chainlint learned to color its output when sent to a terminal. Problem annotations are colored with a red background which stands out well from surrounding text, thus easily draws the reader's attention. Together with the preceding change which gave all problem annotations a uniform "LINT:" prefix, the noisy "?!" decoration has become superfluous as a search "needle" so omit it when output is colored. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-10chainlint: make error messages self-explanatoryEric Sunshine44-90/+104
The annotations emitted by chainlint to indicate detected problems are overly terse, so much so that developers new to the project -- those who should most benefit from the linting -- may find them baffling. For instance, although the author of chainlint and seasoned Git developers may understand that "?!AMP?!" is an abbreviation of "ampersand" and indicates a break in the &&-chain, this may not be obvious to newcomers. The "?!LOOP?!" case is particularly serious because that terse single word does nothing to convey that the loop body should end with "|| return 1" (or "|| exit 1" in a subshell) to ensure that a failing command in the body aborts the loop immediately. Moreover, unlike &&-chaining which is ubiquitous in Git tests, the "|| return 1" idiom is relatively infrequent, thus may be harder for a newcomer to discover by consulting nearby code. Address these shortcomings by emitting human-readable messages which both explain the problem and give a strong hint about how to correct it. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-10chainlint: don't be fooled by "?!...?!" in test bodyEric Sunshine1-5/+8
As originally implemented, chainlint did not collect structured information about detected problems. Instead, it merely emitted raw parse tokens (not the original test text), along with a "?!...?!" annotation directly into the output stream each time a problem was discovered. In order to report statistics (in --stats mode) and to adjust its exit code to indicate success or failure, it merely counts the number of times "?!...?!" appears in the output stream. An obvious shortcoming of this approach is that it can be fooled by a legitimate "?!...?!" sequence in the body of a test (though, only if an actual problem is detected in the test). The situation did not improve when 7c04aa7390 (chainlint: colorize problem annotations and test delimiters, 2022-09-13) colored the annotations after-the-fact by searching for "?!...?!" in the output stream and inserting color codes. As above, a shortcoming is that this approach can incorrectly color a legitimate "?!...?!" sequence in a test body as if it is an error. However, when 73c768dae9 (chainlint: annotate original test definition rather than token stream, 2022-11-08) taught chainlint to output the original test text verbatim, it started collecting structured information about detected problems. Now that it is available, take advantage of the structured problem information to deterministically count the number of problems detected and to color the annotations directly, rather than scanning the output stream for "?!...?!" and performing these operations after-the-fact. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-10ref-filter: fix leak with unterminated %(if) atomsPatrick Steinhardt1-0/+1
When parsing `%(if)` atoms we expect a few other atoms to exist to complete it, like `%(then)` and `%(end)`. Whether or not we have seen these other atoms is tracked in an allocated `if_then_else` structure, which gets free'd by the `if_then_else_handler()` once we have parsed the complete conditional expression. This results in a memory leak when the `%(if)` atom is not terminated correctly and thus incomplete. We never end up executing its handler and thus don't end up freeing the structure. Plug this memory leak by introducing a new `at_end_data_free` callback function. If set, we'll execute it in `pop_stack_element()` and pass it the `at_end_data` variable with the intent to free its state. Wire it up for the `%(if)` atom accordingly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-09ref-filter: add ref_format_clear() functionJeff King1-0/+1
After using the ref-filter API, callers should use ref_filter_clear() to free any used memory. However, there's not a matching function to clear the ref_format struct. Traditionally this did not need to be cleaned up, as it was just a way for the caller to store and pass format options as a single unit. Even though the parsing step of some placeholders may allocate data, that's usually inside their "used_atom" structs, which are part of the ref_filter itself. But a few placeholders keep data outside of there. The %(ahead-behind) and %(is-base) parsers both keep a master list of bases, because they perform a single filtering pass outside of the use of any particular atom. And since the format parser does not have access to the ref_filter struct, they store their cross-atom data in the ref_format struct itself. And thus when they are finished, the ref_format also needs to be cleaned up. So let's add a function to do so, and call it from all of the users of the ref-filter API. The %(is-base) case is found by running LSan on t6300. After this patch, the script can now be marked leak-free. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-09ref-filter: store ref_trailer_buf data per-atomJeff King1-0/+19
The trailer API takes options via a trailer_opts struct. Some of those options point to data structures which require extra storage. Those structures aren't actually embedded in the options struct, but rather we pass pointers, and the caller is responsible for managing them. This is a little convoluted, but makes sense since some of them are not even concrete (e.g., you can pass a filter function and a void data pointer, but the trailer code doesn't even know what's in the pointer). When for-each-ref, etc, parse the %(trailers) placeholder, they stuff the extra data into a ref_trailer_buf struct. But we only hold a single static global instance of this struct. So if a format string has multiple %(trailer) placeholders, they'll stomp on each other: the "key" list will end up with entries for all of them, and the separator buffers will use the values from whichever was parsed last. Instead, we should have a ref_trailer_buf for each instance of the placeholder, and store it alongside the trailer_opts in the used_atom structure. And that's what this patch does. Note that we also have to add code to clean them up in ref_array_clear(). The original code did not bother cleaning them up, but it wasn't technically a "leak" since they were still reachable from the static global instance. Reported-by: Brooke Kuhlmann <brooke@alchemists.io> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-09ref-filter: strip signature when parsing tag trailersJeff King1-0/+18
To expand the "%(trailers)" placeholder, we have to feed the commit or tag body to the trailer API. But that API doesn't know anything about signatures, and will be confused by a signed tag like this: the subject the body Some-trailer: foo -----BEGIN PGP SIGNATURE----- ...etc... because it will start looking for trailers after the signature, and get stopped walking backwards by the very non-trailer signature lines. So it thinks there are no trailers. This problem has existed since %(trailers) was added to the ref-filter code, but back then trailers on tags weren't something we really considered (commits don't have the same problem because their signatures are embedded in the header). But since 066cef7707 (builtin/tag: add --trailer option, 2024-05-05), we'd generate an object like the above for "git tag -s --trailer 'Some-trailer: foo' my-tag". The implementation here is pretty simple: we just make a NUL-terminated copy of the non-signature part of the tag (which we've already parsed) and pass it to the trailer API. There are some alternatives I rejected, at least for now: - the trailer code already understands skipping past some cruft at the end of a commit, such as patch dividers. see find_end_of_log_message(). We could teach it to do the same for signatures. But since this is the only context where we'd want that feature, and since we've already parsed the object into subject/body/signature here, it seemed easier to just pass in the truncated message. - it would be nice if we could just pass in a pointer/len pair to the trailer API (rather than a NUL-terminated string) to avoid the extra copy. I think this is possible, since as noted above, the trailer code already has to deal with ignoring some cruft at the end of the input. But after an initial attempt at this, it got pretty messy, as we have to touch a lot of intermediate functions that are also called in other contexts. So I went for the simple and stupid thing, at least for now. I don't think the extra copy overhead will be all that bad. The previous patch noted that an extra copy seemed to cause about 1-2% slowdown for something simple like "%(subject)". But here we are only triggering it for "%(trailers)" (and only when there is a signature), and the trailer code is a bit allocation-heavy already. I couldn't measure any difference formatting "%(trailers)" on linux.git before and after (even though there are not even any trailers to find). Reported-by: Brooke Kuhlmann <brooke@alchemists.io> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-09t6300: drop newline from wrapped test titleJeff King1-2/+1
We don't usually include newlines in test titles, because you get funny TAP output like: ok 417 - show good signature with custom format ok 418 - show good signature with custom format with ssh ok 419 - signature atom with grade option and bad signature where a TAP parser would ignore the extra line anyway, giving the wrong title. This comes from 26c9c03f0a (ref-filter: add new "signature" atom, 2023-06-04), and I think it was probably just editor line wrapping. I checked for other cases with: git grep "test_expect_success [A-Z_,]* '[^']*$" git grep 'test_expect_success [A-Z_,]* "[^"]*$' but this was the only hit. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-09Merge branch 'cp/unit-test-reftable-stack' into ps/reftable-excludeJunio C Hamano5-27/+1325
* cp/unit-test-reftable-stack: t-reftable-stack: add test for stack iterators t-reftable-stack: add test for non-default compaction factor t-reftable-stack: use reftable_ref_record_equal() to compare ref records t-reftable-stack: use Git's tempfile API instead of mkstemp() t: harmonize t-reftable-stack.c with coding guidelines t: move reftable/stack_test.c to the unit testing framework
2024-09-09t-reftable-stack: add test for stack iteratorsChandra Pratap1-0/+83
reftable_stack_init_ref_iterator and reftable_stack_init_log_iterator as defined by reftable/stack.{c,h} initialize a stack iterator to iterate over the ref and log records in a reftable stack respectively. Since these functions are not exercised by any of the existing tests, add a test for them. Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-09t-reftable-stack: add test for non-default compaction factorChandra Pratap1-4/+37
In a recent codebase update (commit ae8e378430, merge branch 'ps/reftable-write-options', 2024/05/13) the geometric factor used in auto-compaction of reftable tables was made configurable. Add a test to verify the functionality introduced by this update. Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-09t-reftable-stack: use reftable_ref_record_equal() to compare ref recordsChandra Pratap1-2/+2
In the current stack tests, ref records are compared for equality by sometimes using the dedicated function for ref-record comparison, reftable_ref_record_equal(), and sometimes by explicity comparing contents of the ref records. The latter method is undesired because there can exist unequal ref records with some of the contents being equal. Replace the latter instances of ref-record comparison with the former. This has the added benefit of preserving uniformity throughout the test file. Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-09apply: support --ours, --theirs, and --union for three-way mergesAlex Henrie1-0/+40
--ours, --theirs, and --union are already supported in `git merge-file` for automatically resolving conflicts in favor of one version or the other, instead of leaving conflict markers in the file. Support them in `git apply -3` as well because the two commands do the same kind of file-level merges. In case in the future --ours, --theirs, and --union gain a meaning outside of three-way-merges, they do not imply --3way but rather must be specified alongside it. Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-08t-reftable-stack: use Git's tempfile API instead of mkstemp()Chandra Pratap1-1/+3
Git's tempfile API defined by $GIT_DIR/tempfile.{c,h} provides a unified interface for tempfile operations. Since reftable/stack.c uses this API for all its tempfile needs instead of raw functions like mkstemp(), make the ported stack test strictly use Git's tempfile API as well. A bigger benefit is the fact that we know to clean up the tempfile in case the test fails because it gets registered and pruned via a signal handler. Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-08t: harmonize t-reftable-stack.c with coding guidelinesChandra Pratap1-57/+53
Harmonize the newly ported test unit-tests/t-reftable-stack.c with the following guidelines: - Single line 'for' statements must omit curly braces. - Structs must be 0-initialized with '= { 0 }' instead of '= { NULL }'. - Array sizes and indices should preferably be of type 'size_t' and not 'int'. - Function pointers should be passed as 'func' and not '&func'. While at it, remove initialization for those variables that are re-used multiple times, like loop variables. Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-08t: move reftable/stack_test.c to the unit testing frameworkChandra Pratap5-27/+1211
reftable/stack_test.c exercises the functions defined in reftable/stack.{c, h}. Migrate reftable/stack_test.c to the unit testing framework. Migration involves refactoring the tests to use the unit testing framework instead of reftable's test framework and renaming the tests to be in-line with unit-tests' standards. Since some of the tests use set_test_hash() defined by reftable/test_framework.{c, h} but these files are not '#included' in the test file, copy this function in the ported test file. With the migration of stack test to the unit-tests framework, "test-tool reftable" becomes a no-op. Hence, get rid of everything that uses "test-tool reftable" alongside everything that is used to implement it. While at it, alphabetically sort the cmds[] list in helper/test-tool.c by moving the entry for "dump-reftable". Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-08diff: report dirty submodules as changes in builtin_diff()René Scharfe1-0/+21
The diff machinery has two ways to detect changes to set the exit code: Just comparing hashes and comparing blob contents. The latter is needed if certain changes have to be ignored, e.g. with --ignore-space-change or --ignore-matching-lines. It's enabled by the diff_options flag diff_from_contents. The slower mode as never considered submodules (and subrepos) as changes with --submodule=diff or --submodule=log, which is inconsistent with --submodule=short (the default). Fix it. d7b97b7185 (diff: let external diffs report that changes are uninteresting, 2024-06-09) set diff_from_contents if external diff programs are allowed. This is the default e.g. for git diff, and so that change exposed the inconsistency much more widely. Reported-by: David Hull <david.hull@friendbuy.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-08diff: report copies and renames as changes in run_diff_cmd()René Scharfe1-0/+16
The diff machinery has two ways to detect changes to set the exit code: Just comparing hashes and comparing blob contents. The latter is needed if certain changes have to be ignored, e.g. with --ignore-space-change or --ignore-matching-lines. It's enabled by the diff_options flag diff_from_contents. The slower mode has never considered copies and renames to be changes, which is inconsistent with the quicker one. Fix it. Even if we ignore the file contents (because it's empty or contains only ignored lines), there's still the meta data change of adding or changing a filename, so we need to report it in the exit code. d7b97b7185 (diff: let external diffs report that changes are uninteresting, 2024-06-09) set diff_from_contents if external diff programs are allowed. This is the default e.g. for git diff, and so that change exposed the inconsistency much more widely. Reported-by: Jorge Luis Martinez Gomez <jol@jol.dev> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-06scalar: add --no-tags option to 'scalar clone'Derrick Stolee1-0/+18
Some large repositories use tags to track a huge list of release versions. While this choice is costly on the ref advertisement, it is further wasteful for clients who do not need those tags. Allow clients to optionally skip the tag advertisement. This behavior is similar to that of 'git clone --no-tags' implemented in 0dab2468ee5 (clone: add a --no-tags option to clone without tags, 2017-04-26), including the modification of the remote.origin.tagOpt config value to include "--no-tags". One thing that is opposite of the 'git clone' implementation is that this allows '--tags' as an assumed option, which can be naturally negated with '--no-tags'. The clone command does not accept '--tags' but allows "--no-no-tags" as the negation of its '--no-tags' option. While testing this option, combine the test with the previously untested '--no-src' option introduced in 4527db8ff8c (scalar: add --[no-]src option, 2023-08-28). Signed-off-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-06Merge branch 'jk/unused-parameters'Junio C Hamano1-1/+1
Make our codebase compilable with the -Werror=unused-parameter option. * jk/unused-parameters: CodingGuidelines: mention -Wunused-parameter and UNUSED config.mak.dev: enable -Wunused-parameter by default compat: mark unused parameters in win32/mingw functions compat: disable -Wunused-parameter in win32/headless.c compat: disable -Wunused-parameter in 3rd-party code t-reftable-readwrite: mark unused parameter in callback function gc: mark unused config parameter in virtual functions
2024-09-06Merge branch 'jk/send-email-mailmap'Junio C Hamano2-4/+160
"git send-email" learned "--mailmap" option to allow rewriting the recipient addresses. * jk/send-email-mailmap: send-email: add mailmap support via sendemail.mailmap and --mailmap check-mailmap: add options for additional mailmap sources check-mailmap: accept "user@host" contacts
2024-09-06interpret-trailers: handle message without trailing newlineBrian Lyles1-0/+40
When git-interpret-trailers is used to add a trailer to a message that does not end in a trailing newline, the new trailer is added on the line immediately following the message instead of as a trailer block separated from the message by a blank line. For example, if a message's text was exactly "The subject" with no trailing newline present, `git interpret-trailers --trailer my-trailer=true` will result in the following malformed commit message: The subject my-trailer: true While it is generally expected that a commit message should end with a newline character, git-interpret-trailers should not be returning an invalid message in this case. Use `strbuf_complete_line` to ensure that the message ends with a newline character when reading the input. Signed-off-by: Brian Lyles <brianmlyles@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-05drop trailing newline from warning/error/die messagesJeff King3-10/+10
Our error reporting routines append a trailing newline, and the strings we pass to them should not include them (otherwise we get an extra blank line after the message). These cases were all found by looking at the results of: git grep -P '[^_](error|error_errno|warning|die|die_errno)\(.*\\n"[,)]' '*.c' Note that we _do_ sometimes include a newline in the middle of such messages, to create multiline output (hence our grep matching "," or ")" after we see the newline, so we know we're at the end of the string). It's possible that one or more of these cases could intentionally be including a blank line at the end, but having looked at them all manually, I think these are all just mistakes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-05builtin/repack: fix leaking keep-pack listPatrick Steinhardt2-0/+2
The list of packs to keep is populated via a command line option but never free'd. Plug this memory leak. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-05merge-ort: fix two leaks when handling directory rename modificationsPatrick Steinhardt1-0/+1
There are two leaks in `apply_directory_rename_modifications()`: - We do not release the `dirs_to_insert` string list. - We do not release some `conflict_info` we put into the `opt->priv->paths` string map. The former is trivial to fix. The latter is a bit less straight forward: the `util` pointer of the string map may sometimes point to data that has been allocated via `CALLOC()`, while at other times it may point to data that has been allocated via a `mem_pool`. It very much seems like an oversight that we didn't also allocate the conflict info in this code path via the memory pool, though. So let's fix that, which will also plug the memory leak for us. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-05match-trees: fix leaking prefixes in `shift_tree()`Patrick Steinhardt1-0/+1
In `shift_tree()` we allocate two empty strings that we end up passing to `match_trees()`. If that function finds a better match it will update these pointers to point to a newly allocated strings, freeing the old strings. We never free the final results though, neither the ones we have allocated ourselves, nor the one that `match_trees()` might've returned to us. Fix the resulting memory leaks by creating a common exit path where we free them. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-05builtin/fmt-merge-msg: fix leaking buffersPatrick Steinhardt1-0/+1
Fix leaking input and output buffers in git-fmt-merge-msg(1). Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-05builtin/grep: fix leaking object contextPatrick Steinhardt2-0/+3
Even when `get_oid_with_context()` fails it may have allocated some data in the object context. But we do not release it in git-grep(1) when the call fails, leading to a memory leak. Plug it. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-05builtin/pack-objects: plug leaking list of keep-packsPatrick Steinhardt1-0/+1
The `--keep-pack` option of git-pack-objects(1) populates the arguments into a string list. And while the list is marked as `NODUP` and thus won't duplicate the strings, the list entries themselves still need to be free'd. We don't though, causing a leak. Plug it. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-05negotiator/skipping: fix leaking commit entriesPatrick Steinhardt1-0/+2
When releasing the skipping negotiator we free its priority queue, but not the contained entries. Fix this to plug a memory leak. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-05shallow: fix leaking members of `struct shallow_info`Patrick Steinhardt1-0/+1
We do not free several struct members in `clear_shallow_info()`. Fix this to plug the resulting leaks. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-05shallow: free grafts when unregistering themPatrick Steinhardt1-0/+1
When removing a graft via `unregister_shallow()` we remove it from the grafts array, but do not free the structure. Fix this to plug the leak. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-05gpg-interface: fix misdesigned signing key interfacesPatrick Steinhardt1-0/+1
The interfaces to retrieve signing keys and their IDs are misdesigned as they return string constants even though they indeed allocate memory, which leads to memory leaks. Refactor the code to instead always return allocated strings and let the callers free them accordingly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-05remote: fix leak in reachability check of a remote-tracking refPatrick Steinhardt1-0/+1
In `check_if_includes_upstream()` we retrieve the local ref corresponding to a remote-tracking ref we want to check reachability for. We never free that local ref and thus cause a memory leak. Fix this. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-05builtin/submodule--helper: fix leaking refs on push-checkPatrick Steinhardt1-0/+1
In the push-check subcommand of the submodule helper we acquire a list of local refs, but never free that list. Fix this memory leak. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-05submodule: fix leaking fetch task dataPatrick Steinhardt1-0/+1
The `submodule_parallel_fetch` structure contains various data structures that we use to set up parallel fetches of submodules. We do not free some of its data though, causing memory leaks. Plug those. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-05upload-pack: fix leaking child process data on reachability checksPatrick Steinhardt1-0/+1
We spawn a git-rev-list(1) command to perform reachability checks in "upload-pack.c". We do not release memory associated with the process in error cases though, thus leaking memory. Fix these by calling `child_process_clear()`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-05send-pack: fix leaking common object IDsPatrick Steinhardt1-0/+1
We're leaking the array of common object IDs in `send_pack()`. Fix this by creating a common exit path where we free the leaking data. While at it, unify some other cleanups now that we have a central place to put them. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-05t/test-lib: allow skipping leak checks for passing testsPatrick Steinhardt2-1/+13
With `GIT_TEST_PASSING_SANITIZE_LEAK=check`, one can double check whether a memory leak fix caused some test suites to become leak free. This is done by running all tests with the leak checker enabled. If a test suite does not declare `TEST_PASSES_SANITIZE_LEAK=true` but still finishes successfully with the leak checker enabled, then this indicates that the test is leak free and thus missing the annotation. It is somewhat slow to execute though because it runs all of our test suites with the leak sanitizer enabled. It is also pointless in most cases, because the only test suites that need to be checked are those which _aren't_ yet marked with `TEST_PASSES_SANITIZE_LEAK=true`. Introduce a new value "check-failing". When set, we behave the same as if "check" was passed, except that we only check those tests which do not have `TEST_PASSES_SANITIZE_LEAK=true` set. This is significantly faster than running all test suites but still fulfills the usecase of finding newly-leak-free test suites. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-04builtin/cat-file: mark 'git cat-file' sparse-index compatibleKevin Lyles1-0/+36
This change affects how 'git cat-file' works with the index when specifying an object with the ":<path>" syntax (which will give file contents from the index). 'git cat-file' expands a sparse index to a full index any time contents are requested from the index by specifying an object with the ":<path>" syntax. This is true even when the requested file is part of the sparse index, and results in much slower 'git cat-file' operations when working within the sparse index. Mark 'git cat-file' as not needing a full index, so that you only pay the cost of expanding the sparse index to a full index when you request a file outside of the sparse index. Add tests to ensure both that: - 'git cat-file' returns the correct file contents whether or not the file is in the sparse index - 'git cat-file' expands to the full index any time you request something outside of the sparse index Signed-off-by: Kevin Lyles <klyles+github@epic.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-04t1092: allow run_on_* functions to use standard inputKevin Lyles1-5/+9
The 'run_on_sparse' and 'run_on_all' functions do not work correctly for commands accepting standard input, because they run the same command multiple times and the first instance consumes it. This also indirectly affects 'test_all_match' and 'test_sparse_match'. To allow these functions to work with commands accepting standard input, first slurp standard input to a temporary file, and then run the command with its standard input redirected from the temporary file. This ensures that each command sees the same contents from its standard input. Note that this does not impact commands that do not read from standard input; they continue to ignore it. Additionally, existing uses of the run_on_* functions do not need to do anything differently, as the standard input of the test environment is already connected to /dev/null. We do not explicitly clean up the input files because they are cleaned up with the rest of the test repositories and their contents may be useful for figuring out which command failed when a test case fails. Signed-off-by: Kevin Lyles <klyles@epic.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-04t/unit-tests: convert ctype tests to use clarPatrick Steinhardt2-10/+68
Convert the ctype tests to use the new clar unit testing framework. Introduce a new function `cl_failf()` that allows us to print a formatted error message, which we can use to point out which of the characters was classified incorrectly. This results in output like this on failure: # start of suite 1: ctype not ok 1 - ctype::isspace --- reason: | Test failed. 0x0d is classified incorrectly: expected 0, got 1 at: file: 't/unit-tests/ctype.c' line: 36 function: 'test_ctype__isspace' --- ok 2 - ctype::isdigit ok 3 - ctype::isalpha ok 4 - ctype::isalnum ok 5 - ctype::is_glob_special ok 6 - ctype::is_regex_special ok 7 - ctype::is_pathspec_magic ok 8 - ctype::isascii ok 9 - ctype::islower ok 10 - ctype::isupper ok 11 - ctype::iscntrl ok 12 - ctype::ispunct ok 13 - ctype::isxdigit ok 14 - ctype::isprint Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-04t/unit-tests: convert strvec tests to use clarPatrick Steinhardt2-211/+241
Convert the strvec tests to use the new clar unit testing framework. This is a first test balloon that demonstrates how the testing infra for clar-based tests looks like. The tests are part of the "t/unit-tests/bin/unit-tests" binary. When running that binary with an injected error, it generates TAP output: # ./t/unit-tests/bin/unit-tests TAP version 13 # start of suite 1: strvec ok 1 - strvec::init ok 2 - strvec::dynamic_init ok 3 - strvec::clear not ok 4 - strvec::push --- reason: | String mismatch: (&vec)->v[i] != expect[i] 'foo' != 'fo' (at byte 2) at: file: 't/unit-tests/strvec.c' line: 48 function: 'test_strvec__push' --- ok 5 - strvec::pushf ok 6 - strvec::pushl ok 7 - strvec::pushv ok 8 - strvec::replace_at_head ok 9 - strvec::replace_at_tail ok 10 - strvec::replace_in_between ok 11 - strvec::replace_with_substring ok 12 - strvec::remove_at_head ok 13 - strvec::remove_at_tail ok 14 - strvec::remove_in_between ok 15 - strvec::pop_empty_array ok 16 - strvec::pop_non_empty_array ok 17 - strvec::split_empty_string ok 18 - strvec::split_single_item ok 19 - strvec::split_multiple_items ok 20 - strvec::split_whitespace_only ok 21 - strvec::split_multiple_consecutive_whitespaces ok 22 - strvec::detach 1..22 The binary also supports some parameters that allow us to run only a subset of unit tests or alter the output: $ ./t/unit-tests/bin/unit-tests -h Usage: ./t/unit-tests/bin/unit-tests [options] Options: -sname Run only the suite with `name` (can go to individual test name) -iname Include the suite with `name` -xname Exclude the suite with `name` -v Increase verbosity (show suite names) -q Only report tests that had an error -Q Quit as soon as a test fails -t Display results in tap format -l Print suite names -r[filename] Write summary file (to the optional filename) Furthermore, running `make unit-tests` runs the binary along with all the other unit tests we have. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-04t/unit-tests: implement test driverPatrick Steinhardt1-2/+43
The test driver in "unit-test.c" is responsible for setting up our unit tests and eventually running them. As such, it is also responsible for parsing the command line arguments. The clar unit testing framework provides function `clar_test()` that parses command line arguments and then executes the tests for us. In theory that would already be sufficient. We have the special requirement to always generate TAP-formatted output though, so we'd have to always pass the "-t" argument to clar. Furthermore, some of the options exposed by clar are ineffective when "-t" is used, but they would still be shown when the user passes the "-h" parameter to have the clar show its usage. Implement our own option handling instead of using the one provided by clar, which gives us greater flexibility in how exactly we set things up. We would ideally not use any "normal" code of ours for this such that the unit testing framework doesn't depend on it working correctly. But it is somewhat dubious whether we really want to reimplement all of the option parsing. So for now, let's be pragmatic and reuse it until we find a good reason in the future why we'd really want to avoid it. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-04Makefile: wire up the clar unit testing frameworkPatrick Steinhardt5-0/+62
Wire up the clar unit testing framework by introducing a new "unit-tests" executable. In contrast to the existing framework, this will result in a single executable for all test suites. The ability to pick specific tests to execute is retained via functionality built into the clar itself. Note that we need to be a bit careful about how we need to invalidate our Makefile rules. While we obviously have to regenerate the clar suite when our test suites change, we also have to invalidate it in case any of the test suites gets removed. We do so by using our typical pattern of creating a `GIT-TEST-SUITES` file that gets updated whenever the set of test suites changes, so that we can easily depend on that file. Another specialty is that we generate a "clar-decls.h" file. The test functions are neither static, nor do they have external declarations. This is because they are getting parsed via "generate.py", which then creates the external generations that get populated into an array. These declarations are only seen by the main function though. The consequence is that we will get a bunch of "missing prototypes" errors from our compiler for each of these test functions. To fix those errors, we extract the `extern` declarations from "clar.suite" and put them into a standalone header that then gets included by each of our unit tests. This gets rid of compiler warnings for every function which has been extracted by "generate.py". More importantly though, it does _not_ get rid of warnings in case a function really isn't being used by anything. Thus, it would cause a compiler error if a function name was mistyped and thus not picked up by "generate.py". The test driver "unit-test.c" is an empty stub for now. It will get implemented in the next commit. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-04clar: stop including `shellapi.h` unnecessarilyJohannes Schindelin1-1/+1
The `shellapi.h` header was included as of https://github.com/clar-test/clar/commit/136e763211aa, to have `SHFileOperation()` declared so that it could be called. However, https://github.com/clar-test/clar/commit/5ce31b69b525 removed that call, and therefore that `#include <shellapi.h>` is unnecessary. It is also unwanted in Git because this project uses a subset of Git for Windows' SDK in its CI builds that (for bandwidth reasons) excludes tons of header files, including `shellapi.h`. So let's remove it. Note: Since the `windows.h` header would include `shellapi.h` anyway, we also define `WIN32_LEAN_AND_MEAN` to avoid this and similar other unnecessary includes before including `windows.h`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-04clar(win32): avoid compile error due to unused `fs_copy()`Johannes Schindelin1-0/+2
When CLAR_FIXTURE_PATH is unset, the `fs_copy()` function seems not to be used. But it is declared as `static`, and GCC does not like that, complaining that it should not be declared/defined to begin with. We could mark this function as (potentially) unused by following the `MAYBE_UNUSED` pattern from Git's `git-compat-util.h`. However, this is a GCC-only construct that is not understood by Visual C. Besides, `clar` does not use that pattern at all. Instead, let's use the `((void)SYMBOL);` pattern that `clar` already uses elsewhere; This avoids the compile error by sorta kinda make the function used after a fashion. Note: GCC 14.x (which Git for Windows' SDK already uses) is able to figure out that this function is unused even though there are recursive calls between `fs_copy()` and `fs_copydir_helper()`; Earlier GCC versions do not detect that, and therefore the issue has been hidden from the regular Linux CI builds (where GCC 14.x is not yet used). That is the reason why this change is only made in the Windows-specific portion of `t/unit-tests/clar/clar/fs.h`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-04clar: avoid compile error with mingw-w64Johannes Schindelin1-1/+1
When using mingw-w64 to compile the code, and using `_stat()`, it is necessary to use `struct _stat`, too, and not `struct stat` (as the latter is incompatible with the "dashed" version because it is limited to 32-bit time types for backwards compatibility). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-04t/clar: fix compatibility with NonStopPatrick Steinhardt1-0/+6
The NonStop platform does not have `mkdtemp()` available, which we rely on in `build_sandbox_path()`. Fix this issue by using `mktemp()` and `mkdir()` instead on this platform. This has been cherry-picked from the upstream pull request at [1]. [1]: https://github.com/clar-test/clar/pull/96 Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-04t: import the clar unit testing frameworkPatrick Steinhardt18-0/+2938
Our unit testing framework is a homegrown solution. While it supports most of our needs, it is likely that the volume of unit tests will grow quite a bit in the future such that we can exercise low-level subsystems directly. This surfaces several shortcomings that the current solution has: - There is no way to run only one specific tests. While some of our unit tests wire this up manually, others don't. In general, it requires quite a bit of boilerplate to get this set up correctly. - Failures do not cause a test to stop execution directly. Instead, the test author needs to return manually whenever an assertion fails. This is rather verbose and is not done correctly in most of our unit tests. - Wiring up a new testcase requires both implementing the test function and calling it in the respective test suite's main function, which is creating code duplication. We can of course fix all of these issues ourselves, but that feels rather pointless when there are already so many unit testing frameworks out there that have those features. We line out some requirements for any unit testing framework in "Documentation/technical/unit-tests.txt". The "clar" unit testing framework, which isn't listed in that table yet, ticks many of the boxes: - It is licensed under ISC, which is compatible. - It is easily vendorable because it is rather tiny at around 1200 lines of code. - It is easily hackable due to the same reason. - It has TAP support. - It has skippable tests. - It preprocesses test files in order to extract test functions, which then get wired up automatically. While it's not perfect, the fact that clar originates from the libgit2 project means that it should be rather easy for us to collaborate with upstream to plug any gaps. Import the clar unit testing framework at commit 1516124 (Merge pull request #97 from pks-t/pks-whitespace-fixes, 2024-08-15). The framework will be wired up in subsequent commits. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-04t: do not pass GIT_TEST_OPTS to unit tests with provePatrick Steinhardt2-2/+3
When using the prove target, we append GIT_TEST_OPTS to the arguments that we execute each of the tests with. This doesn't only include the intended test scripts, but also ends up passing the arguments to our unit tests. This is unintentional though as they do not even know to interpret those arguments, and is inconsistent with how we execute unit tests without prove. This isn't much of an issue because our current set of unit tests mostly ignore their arguments anyway. With the introduction of clar-based unit tests this is about to become an issue though, as these do parse their command line argument to alter behaviour. Prepare for this by passing GIT_TEST_OPTS to "run-test.sh" via an environment variable. Like this, we can conditionally forward it to our test scripts, only. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-04refs/files: use heuristic to decide whether to repack with `--auto`Patrick Steinhardt1-10/+75
The `--auto` flag for git-pack-refs(1) allows the ref backend to decide whether or not a repack is in order. This switch has been introduced mostly with the "reftable" backend in mind, which already knows to auto-compact its tables during normal operations. When the flag is set, then it will use the same auto-compaction mechanism and thus end up doing nothing in most cases. The "files" backend does not have any such heuristic yet and instead packs any loose references unconditionally. So we rewrite the complete "packed-refs" file even if there's only a single loose reference to be packed. Even worse, starting with 9f6714ab3e (builtin/gc: pack refs when using `git maintenance run --auto`, 2024-03-25), `git pack-refs --auto` is unconditionally executed via our auto maintenance, so we end up repacking references every single time auto maintenance kicks in. And while that commit already mentioned that the "files" backend unconditionally packs refs now, the author obviously didn't quite think about the consequences thereof. So while the idea was sound, we really should have added a heuristic to the "files" backend before implementing it. Introduce a heuristic that decides whether or not it is worth to pack loose references. The important factors to decide here are the number of loose references in comparison to the overall size of the "packed-refs" file. The bigger the "packed-refs" file, the longer it takes to rewrite it and thus we scale up the limit of allowed loose references before we repack. As is the nature of heuristics, this mechansim isn't obviously "correct", but should rather be seen as a tradeoff between how much resources we spend packing refs and how inefficient the ref store becomes. For all I can say, we have successfully been using the exact same heuristic in Gitaly for several years by now. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-04t0601: merge tests for auto-packing of refsPatrick Steinhardt1-16/+20
We have two tests in t0601 which exercise the same underlying logic, once via `git pack-refs --auto` and once via `git maintenance run --auto`. Merge these two tests into one such that it becomes easier to extend test coverage for both commands at the same time. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-04builtin/index-pack: fix segfaults when running outside of a repoPatrick Steinhardt1-0/+39
It was reported that git-verify-pack(1) has started to crash with Git v2.46.0 when run outside of a repository. This is another fallout from c8aed5e8da (repository: stop setting SHA1 as the default object hash, 2024-05-07), where we have stopped setting the default hash algorithm for `the_repository`. Consequently, code that relies on `the_hash_algo` will now crash when it hasn't explicitly been initialized, which may be the case when running outside of a Git repository. The crash is not in git-verify-pack(1) but instead in git-index-pack(1), which gets called by the former. Ideally, both of these programs should be able to identify the hash algorithm used by the packfile and index without having to rely on external information. But unfortunately, the format for neither of them is completely self-describing, so it is not possible to derive that information. This is a design issue that we should address by introducing a new packfile version that encodes its object hash. For now though the more important fix is to not make either of these programs crash anymore, which we do by falling back to SHA1 when the object hash is unconfigured. This pessimizes reading packfiles which use a different hash than SHA1, but restores previous behaviour. Reported-by: Ilya K <me@0upti.me> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-03rebase: apply and cleanup autostash when rebase fails to startPhillip Wood3-3/+49
If "git rebase" fails to start after stashing the user's uncommitted changes then it forgets to restore the stashed changes and remove the state directory. To make matters worse, running "git rebase --abort" to apply the stashed changes and cleanup the state directory fails because the state directory only contains the "autostash" file and is missing the "head-name" and "onto" files required by read_basic_state(). Fix this by applying the autostash and removing the state directory if the pre-rebase hook or initial checkout fail. This matches what finish_rebase() does at the end of a successful rebase. If the user modifies any files after the autostash is created it is possible there will be conflicts when the autostash is applied. In that case apply_autostash() saves the stash in a new entry under refs/stash and so it is safe to remove the state directory containing the autostash file. New tests are added to check the autostash is applied and the state directory is removed if the rebase fails to start. Checks are also added to some existing tests in order to ensure there is no state directory left behind when a rebase fails to start and no autostash has been created. Reported-by: Brian Lyles <brianmlyles@gmail.com> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-09-03Merge branch 'ps/reftable-concurrent-compaction'Junio C Hamano4-53/+56
The code path for compacting reftable files saw some bugfixes against concurrent operation. * ps/reftable-concurrent-compaction: reftable/stack: fix segfault when reload with reused readers fails reftable/stack: reorder swapping in the reloaded stack contents reftable/reader: keep readers alive during iteration reftable/reader: introduce refcounting reftable/stack: fix broken refnames in `write_n_ref_tables()` reftable/reader: inline `reader_close()` reftable/reader: inline `init_reader()` reftable/reader: rename `reftable_new_reader()` reftable/stack: inline `stack_compact_range_stats()` reftable/blocksource: drop malloc block source
2024-09-03Merge branch 'ps/leakfixes-part-5'Junio C Hamano24-1/+35
Even more leak fixes. * ps/leakfixes-part-5: transport: fix leaking negotiation tips transport: fix leaking arguments when fetching from bundle builtin/fetch: fix leaking transaction with `--atomic` remote: fix leaking peer ref when expanding refmap remote: fix leaks when matching refspecs remote: fix leaking config strings builtin/fetch-pack: fix leaking refs sideband: fix leaks when configuring sideband colors builtin/send-pack: fix leaking refspecs transport: fix leaking OID arrays in git:// transport data t/helper: fix leaking multi-pack-indices in "read-midx" builtin/repack: fix leaks when computing packs to repack midx-write: fix leaking hashfile on error cases builtin/archive: fix leaking `OPT_FILENAME()` value builtin/upload-archive: fix leaking args passed to `write_archive()` builtin/merge-tree: fix leaking `-X` strategy options pretty: fix leaking key/value separator buffer pretty: fix memory leaks when parsing pretty formats convert: fix leaks when resetting attributes mailinfo: fix leaking header data
2024-09-01t: port helper/test-oid-array.c to unit-tests/t-oid-array.cGhanshyam Thakkar7-174/+135
helper/test-oid-array.c along with t0064-oid-array.sh test the oid-array.h API, which provides storage and processing efficiency over large lists of object identifiers. Migrate them to the unit testing framework for better runtime performance and efficiency. As we don't initialize a repository in these tests, the hash algo that functions like oid_array_lookup() use is not initialized, therefore call repo_set_hash_algo() to initialize it. And init_hash_algo():lib-oid.c can aid in this process, so make it public. Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Helped-by: Phillip Wood <phillip.wood123@gmail.com> Signed-off-by: Ghanshyam Thakkar <shyamthakkar001@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-29Merge branch 'ds/sparse-diff-index'Junio C Hamano1-3/+12
The underlying machinery for "git diff-index" has long been made to expand the sparse index as needed, but the command fully expanded the sparse index upfront, which now has been taught not to do. * ds/sparse-diff-index: diff-index: integrate with the sparse index
2024-08-29Merge branch 'cp/unit-test-reftable-block'Junio C Hamano2-1/+370
Another test for reftable library ported to the unit test framework. * cp/unit-test-reftable-block: t-reftable-block: mark unused argv/argc t-reftable-block: add tests for index blocks t-reftable-block: add tests for obj blocks t-reftable-block: add tests for log blocks t-reftable-block: remove unnecessary variable 'j' t-reftable-block: use xstrfmt() instead of xstrdup() t-reftable-block: use block_iter_reset() instead of block_iter_close() t-reftable-block: use reftable_record_key() instead of strbuf_addstr() t-reftable-block: use reftable_record_equal() instead of check_str() t-reftable-block: release used block reader t: harmonize t-reftable-block.c with coding guidelines t: move reftable/block_test.c to the unit testing framework
2024-08-29Merge branch 'ps/reftable-drop-generic'Junio C Hamano2-14/+192
The code in the reftable library has been cleaned up by discarding unused "generic" interface. * ps/reftable-drop-generic: reftable: mark unused parameters in empty iterator functions reftable/generic: drop interface t/helper: refactor to not use `struct reftable_table` t/helper: use `hash_to_hex_algop()` to print hashes t/helper: inline printing of reftable records t/helper: inline `reftable_table_print()` t/helper: inline `reftable_stack_print_directory()` t/helper: inline `reftable_reader_print_file()` t/helper: inline `reftable_dump_main()` reftable/dump: drop unused `compact_stack()` reftable/generic: move generic iterator code into iterator interface reftable/iter: drop double-checking logic reftable/stack: open-code reading refs reftable/merged: stop using generic tables in the merged table reftable/merged: rename `reftable_new_merged_table()` reftable/merged: expose functions to initialize iterators
2024-08-28Merge branch 'gt/unit-test-urlmatch-normalization'Junio C Hamano17-260/+271
Another rewrite of test. * gt/unit-test-urlmatch-normalization: t: migrate t0110-urlmatch-normalization to the new framework
2024-08-28Merge branch 'mt/rebase-x-quiet'Junio C Hamano1-0/+6
"git rebase -x --quiet" was not quiet, which was corrected. * mt/rebase-x-quiet: rebase --exec: respect --quiet
2024-08-28t-reftable-block: mark unused argv/argcJeff King1-1/+1
This is conceptually the same as the cases in df9d638c24 (unit-tests: ignore unused argc/argv, 2024-08-17), but this unit test was migrated from the reftable tests in a parallel branch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-28t-reftable-readwrite: mark unused parameter in callback functionJeff King1-1/+1
This spot was originally marked in in 4695c3f3a9 (reftable: mark unused parameters in virtual functions, 2024-08-17), but was copied in 5b539a5361 (t: move reftable/readwrite_test.c to the unit testing framework, 2024-08-13). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-27send-email: add mailmap support via sendemail.mailmap and --mailmapJacob Keller1-0/+122
In some cases, a user may be generating a patch for an old commit which now has an out-of-date author or other identity. For example, consider a team member who contributes to an internal fork of an upstream project, but leaves before this change is submitted upstream. In this case, the team members company address may no longer be valid, and will thus bounce when sending email. This can be manually avoided by editing the generated patch files, or by carefully using --suppress-<cc|to> options. This requires a lot of manual intervention and is easy to forget. Git has support for mapping old email addresses and names to a canonical name and address via the .mailmap file (and its associated mailmap.file, mailmap.blob, and log.mailmap options). Teach git send-email to enable mailmap support for all addresses. This ensures that addresses point to the canonical real name and email address. Add the sendemail.mailmap configuration option and its associated --mailmap (and --use-mailmap for compatibility with git log) options. For now, the default behavior is to disable the mailmap in order to avoid any surprises or breaking any existing setups. These options support per-identity configuration via the sendemail.identity configuration blocks. This enables identity-specific configuration in cases where users may not want to enable support. In addition, support send-email specific mailmap data via sendemail.mailmap.file, sendemail.mailmap.blob and their identity-specific variants. The intention of these options is to enable mapping addresses which are no longer valid to a current project or team maintainer. Such mappings may change the actual person being referred to, and may not make sense in a traditional mailmap file which is intended for updating canonical name and address for the same individual. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-27check-mailmap: accept "user@host" contactsJacob Keller1-4/+38
git check-mailmap splits each provided contact using split_ident_line. This function requires that the contact either be of the form "Name <user@host>" or of the form "<user@host>". In particular, if the mail portion of the contact is not surrounded by angle brackets, split_ident_line will reject it. This results in git check-mailmap rejecting attempts to translate simple email addresses: $ git check-mailmap user@host fatal: unable to parse contact: user@host This limits the usability of check-mailmap as it requires placing angle brackets around plain email addresses. In particular, attempting to use git check-mailmap to support mapping addresses in git send-email is not straight forward. The sanitization and validation functions in git send-email strip angle brackets from plain email addresses. It is not trivial to add brackets prior to invoking git check-mailmap. Instead, modify check_mailmap() to allow such strings as contacts. In particular, treat any line which cannot be split by split_ident_line as a simple email address. No attempt is made to actually parse the address line, or validate that it is actually an email address. Implementing such validation is not trivial. Besides, we weren't validating the address between angle brackets before anyways. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-27builtin/pack-objects.c: translate bit positions during pack-reuseTaylor Blau1-4/+27
When reusing chunks verbatim from an existing source pack, the function write_reused_pack() first attempts to reuse whole words (via the function `write_reused_pack_verbatim()`), and then individual bits (via `write_reused_pack_one()`). In the non-MIDX case, all of this code works fine. Likewise, in the MIDX case, processing bits individually from the first (preferred) pack works fine. However, processing subsequent packs in the MIDX case is broken when there are duplicate objects among the set of MIDX'd packs. This is because we treat the individual bit positions as valid pack positions within the source pack(s), which does not account for gaps in the source pack, like we see when the MIDX must break ties between duplicate objects which appear in multiple packs. The broken code looks like: for (; i < reuse_packfile_bitmap->word_alloc; i++) { for (offset = 0; offset < BITS_IN_EWORD, offset++) { /* ... */ write_reused_pack_one(reuse_packfile->p, pos + offset - reuse_packfile->bitmap_pos, f, pack_start, &w_curs); } } , where the second argument is incorrect and does not account for gaps. Instead, make sure that we translate bit positions in the MIDX's pseudo-pack order to pack positions in the respective source packs by: - Translating the bit position (pseudo-pack order) to a MIDX position (lexical order). - Use the MIDX position to obtain the offset at which the given object occurs in the source pack. - Then translate that offset back into a pack relative position within the source pack by calling offset_to_pack_pos(). After doing this, then we can safely use the result as a pack position. Note that when doing single-pack reuse, as well as reusing objects from the MIDX's preferred pack, such translation is not necessary, since either ties are broken in favor of the preferred pack, or there are no ties to break at all (in the case of non-MIDX bitmaps). Failing to do this can result in strange failure modes. One example that can occur when misinterpreting bits in the above fashion is that Git thinks it's supposed to send a delta that the caller does not want. Under this (incorrect) assumption, we try to look up the delta's base (so that we can patch any OFS_DELTAs if necessary). We do this using find_reused_offset(). But if we try and call that function for an offset belonging to an object we did not send, we'll get back garbage. This can result in us computing a negative fixup value, which results in memory corruption when trying to write the (patched) OFS_DELTA header. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-27t/t5332-multi-pack-reuse.sh: verify pack generation with --strictTaylor Blau1-8/+12
In our tests for multi-pack reuse, we have two helper functions: - test_pack_objects_reused_all(), and - test_pack_objects_reused() which invoke pack-objects (either with `--all`, or the supplied tips via stdin, respectively) and ensure that (a) the number of reused objects, and (b) the number of packs which those objects were reused from both match the expected values. Both functions discard the output of pack-objects and assert only on the contents of the trace2 stream. However, if we store the pack and attempt to index it with `--strict`, we find that a number of our tests are broken, indicating a bug within multi-pack reuse. That bug will be addressed in a subsequent commit. But let's first harden these tests by trying to index the resulting pack, marking the tests which fail appropriately. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-26Merge branch 'ds/for-each-ref-is-base'Junio C Hamano4-0/+163
'git for-each-ref' learned a new "--format" atom to find the branch that the history leading to a given commit "%(is-base:<commit>)" is likely based on. * ds/for-each-ref-is-base: p1500: add is-base performance tests for-each-ref: add 'is-base' token commit: add gentle reference lookup method commit-reach: add get_branch_base_for_tip
2024-08-26Merge branch 'jk/send-email-translate-aliases'Junio C Hamano1-6/+112
"git send-email" learned "--translate-aliases" option that reads addresses from the standard input and emits the result of applying aliases on them to the standard output. * jk/send-email-translate-aliases: send-email: teach git send-email option to translate aliases t9001-send-email.sh: update alias list used for pine test t9001-send-email.sh: fix quoting for mailrc --dump-aliases test
2024-08-26Merge branch 'jk/mark-unused-parameters'Junio C Hamano18-20/+20
Mark unused parameters as UNUSED to squelch -Wunused warnings. * jk/mark-unused-parameters: t-hashmap: stop calling setup() for t_intern() test scalar: mark unused parameters in dummy function daemon: mark unused parameters in non-posix fallbacks setup: mark unused parameter in config callback test-mergesort: mark unused parameters in trivial callback t-hashmap: mark unused parameters in callback function reftable: mark unused parameters in virtual functions reftable: drop obsolete test function declarations reftable: ignore unused argc/argv in test functions unit-tests: ignore unused argc/argv t/helper: mark more unused argv/argc arguments oss-fuzz: mark unused argv/argc argument refs: mark unused parameters in do_for_each_reflog_helper() refs: mark unused parameters in ref_store fsck callbacks update-ref: mark more unused parameters in parser callbacks imap-send: mark unused parameter in ssl_socket_connect() fallback
2024-08-26Merge branch 'tb/pseudo-merge-bitmap-fixes'Junio C Hamano1-0/+56
We created a useless pseudo-merge reachability bitmap that is about 0 commits, and attempted to include commits that are not in packs, which made no sense. These bugs have been corrected. * tb/pseudo-merge-bitmap-fixes: pseudo-merge.c: ensure pseudo-merge groups are closed pseudo-merge.c: do not generate empty pseudo-merge commits t/t5333-pseudo-merge-bitmaps.sh: demonstrate empty pseudo-merge groups pack-bitmap-write.c: select pseudo-merges even for small bitmaps pack-bitmap: drop redundant args from `bitmap_writer_finish()` pack-bitmap: drop redundant args from `bitmap_writer_build()` pack-bitmap: drop redundant args from `bitmap_writer_build_type_index()` pack-bitmap: initialize `bitmap_writer_init()` with packing_data
2024-08-26Merge branch 'ps/maintenance-detach-fix-more'Junio C Hamano1-6/+25
A tests for "git maintenance" that were broken on Windows have been corrected. * ps/maintenance-detach-fix-more: builtin/maintenance: fix loose objects task emitting pack hash t7900: exercise detaching via trace2 regions t7900: fix flaky test due to leaking background job
2024-08-26Merge branch 'ps/maintenance-detach-fix'Junio C Hamano4-16/+118
Maintenance tasks other than "gc" now properly go background when "git maintenance" runs them. * ps/maintenance-detach-fix: run-command: fix detaching when running auto maintenance builtin/maintenance: add a `--detach` flag builtin/gc: add a `--detach` flag builtin/gc: stop processing log file on signal builtin/gc: fix leaking config values builtin/gc: refactor to read config into structure config: fix constness of out parameter for `git_config_get_expiry()`
2024-08-26Merge branch 'xx/diff-tree-remerge-diff-fix' into maint-2.46Junio C Hamano1-0/+35
"git rev-list ... | git diff-tree -p --remerge-diff --stdin" should behave more or less like "git log -p --remerge-diff" but instead it crashed, forgetting to prepare a temporary object store needed. * xx/diff-tree-remerge-diff-fix: diff-tree: fix crash when used with --remerge-diff
2024-08-26Merge branch 'rs/t-example-simplify' into maint-2.46Junio C Hamano1-16/+8
Unit test simplification. * rs/t-example-simplify: t-example-decorate: remove test messages
2024-08-26Merge branch 'jc/safe-directory' into maint-2.46Junio C Hamano1-0/+178
Follow-up on 2.45.1 regression fix. * jc/safe-directory: safe.directory: setting safe.directory="." allows the "current" directory safe.directory: normalize the configured path safe.directory: normalize the checked path safe.directory: preliminary clean-up
2024-08-26Merge branch 'kl/test-fixes' into maint-2.46Junio C Hamano3-6/+12
A flakey test and incorrect calls to strtoX() functions have been fixed. * kl/test-fixes: t6421: fix test to work when repo dir contains d0 set errno=0 before strtoX calls
2024-08-26Merge branch 'jc/reflog-expire-lookup-commit-fix' into maint-2.46Junio C Hamano1-0/+8
"git reflog expire" failed to honor annotated tags when computing reachable commits. * jc/reflog-expire-lookup-commit-fix: Revert "reflog expire: don't use lookup_commit_reference_gently()"
2024-08-26Merge branch 'jc/leakfix-mailmap' into maint-2.46Junio C Hamano1-0/+1
Leakfix. * jc/leakfix-mailmap: mailmap: plug memory leak in read_mailmap_blob()
2024-08-26Merge branch 'jc/leakfix-hashfile' into maint-2.46Junio C Hamano1-0/+1
Leakfix. * jc/leakfix-hashfile: csum-file: introduce discard_hashfile()
2024-08-26Merge branch 'jc/jl-git-no-advice-fix' into maint-2.46Junio C Hamano1-1/+0
Remove leftover debugging cruft from a test script. * jc/jl-git-no-advice-fix: t0018: remove leftover debugging cruft
2024-08-26Merge branch 'tb/config-fixed-value-with-valueless-true' into maint-2.46Junio C Hamano1-0/+9
"git config --value=foo --fixed-value section.key newvalue" barfed when the existing value in the configuration file used the valueless true syntax, which has been corrected. * tb/config-fixed-value-with-valueless-true: config.c: avoid segfault with --fixed-value and valueless config
2024-08-26Merge branch 'ps/ls-remote-out-of-repo-fix' into maint-2.46Junio C Hamano1-0/+13
A recent update broke "git ls-remote" used outside a repository, which has been corrected. * ps/ls-remote-out-of-repo-fix: builtin/ls-remote: fall back to SHA1 outside of a repo
2024-08-23Merge branch 'ps/stash-keep-untrack-empty-fix'Junio C Hamano1-0/+15
A corner case bug in "git stash" was fixed. * ps/stash-keep-untrack-empty-fix: builtin/stash: fix `--keep-index --include-untracked` with empty HEAD
2024-08-23Merge branch 'ps/hash-and-ref-format-from-config'Junio C Hamano1-13/+132
The default object hash and ref backend format used to be settable only with explicit command line option to "git init" and environment variables, but now they can be configured in the user's global and system wide configuration. * ps/hash-and-ref-format-from-config: setup: make ref storage format configurable via config setup: make object format configurable via config setup: merge configuration of repository formats t0001: delete repositories when object format tests finish t0001: exercise initialization with ref formats more thoroughly
2024-08-23Merge branch 'cp/unit-test-reftable-readwrite'Junio C Hamano2-1/+974
* cp/unit-test-reftable-readwrite: t-reftable-readwrite: add test for known error t-reftable-readwrite: use 'for' in place of infinite 'while' loops t-reftable-readwrite: use free_names() instead of a for loop t: move reftable/readwrite_test.c to the unit testing framework
2024-08-23Merge branch 'ps/config-wo-the-repository'Junio C Hamano3-0/+6
Use of API functions that implicitly depend on the_repository object in the config subsystem has been rewritten to pass a repository object through the callchain. * ps/config-wo-the-repository: config: hide functions using `the_repository` by default global: prepare for hiding away repo-less config functions config: don't depend on `the_repository` with branch conditions config: don't have setters depend on `the_repository` config: pass repo to functions that rename or copy sections config: pass repo to `git_die_config()` config: pass repo to `git_config_get_expiry_in_days()` config: pass repo to `git_config_get_expiry()` config: pass repo to `git_config_get_max_percent_split_change()` config: pass repo to `git_config_get_split_index()` config: pass repo to `git_config_get_index_threads()` config: expose `repo_config_clear()` config: introduce missing setters that take repo as parameter path: hide functions using `the_repository` by default path: stop relying on `the_repository` in `worktree_git_path()` path: stop relying on `the_repository` when reporting garbage hooks: remove implicit dependency on `the_repository` editor: do not rely on `the_repository` for interactive edits path: expose `do_git_common_path()` as `repo_common_pathv()` path: expose `do_git_path()` as `repo_git_pathv()`
2024-08-23Merge branch 'ps/leakfixes-part-4'Junio C Hamano32-1/+38
More leak fixes. * ps/leakfixes-part-4: (22 commits) builtin/diff: free symmetric diff members diff: free state populated via options builtin/log: fix leak when showing converted blob contents userdiff: fix leaking memory for configured diff drivers builtin/format-patch: fix various trivial memory leaks diff: fix leak when parsing invalid ignore regex option unpack-trees: clear index when not propagating it sequencer: release todo list on error paths merge-ort: unconditionally release attributes index builtin/fast-export: plug leaking tag names builtin/fast-export: fix leaking diff options builtin/fast-import: plug trivial memory leaks builtin/notes: fix leaking `struct notes_tree` when merging notes builtin/rebase: fix leaking `commit.gpgsign` value config: fix leaking comment character config submodule-config: fix leaking name entry when traversing submodules read-cache: fix leaking hashfile when writing index fails bulk-checkin: fix leaking state TODO object-name: fix leaking symlink paths in object context object-file: fix memory leak when reading corrupted headers ...
2024-08-23reftable/reader: introduce refcountingPatrick Steinhardt2-3/+3
It was recently reported that concurrent reads and writes may cause the reftable backend to segfault. The root cause of this is that we do not properly keep track of reftable readers across reloads. Suppose that you have a reftable iterator and then decide to reload the stack while iterating through the iterator. When the stack has been rewritten since we have created the iterator, then we would end up discarding a subset of readers that may still be in use by the iterator. The consequence is that we now try to reference deallocated memory, which of course segfaults. One way to trigger this is in t5616, where some background maintenance jobs have been leaking from one test into another. This leads to stack traces like the following one: + git -c protocol.version=0 -C pc1 fetch --filter=blob:limit=29999 --refetch origin AddressSanitizer:DEADLYSIGNAL ================================================================= ==657994==ERROR: AddressSanitizer: SEGV on unknown address 0x7fa0f0ec6089 (pc 0x55f23e52ddf9 bp 0x7ffe7bfa1700 sp 0x7ffe7bfa1700 T0) ==657994==The signal is caused by a READ memory access. #0 0x55f23e52ddf9 in get_var_int reftable/record.c:29 #1 0x55f23e53295e in reftable_decode_keylen reftable/record.c:170 #2 0x55f23e532cc0 in reftable_decode_key reftable/record.c:194 #3 0x55f23e54e72e in block_iter_next reftable/block.c:398 #4 0x55f23e5573dc in table_iter_next_in_block reftable/reader.c:240 #5 0x55f23e5573dc in table_iter_next reftable/reader.c:355 #6 0x55f23e5573dc in table_iter_next reftable/reader.c:339 #7 0x55f23e551283 in merged_iter_advance_subiter reftable/merged.c:69 #8 0x55f23e55169e in merged_iter_next_entry reftable/merged.c:123 #9 0x55f23e55169e in merged_iter_next_void reftable/merged.c:172 #10 0x55f23e537625 in reftable_iterator_next_ref reftable/generic.c:175 #11 0x55f23e2cf9c6 in reftable_ref_iterator_advance refs/reftable-backend.c:464 #12 0x55f23e2d996e in ref_iterator_advance refs/iterator.c:13 #13 0x55f23e2d996e in do_for_each_ref_iterator refs/iterator.c:452 #14 0x55f23dca6767 in get_ref_map builtin/fetch.c:623 #15 0x55f23dca6767 in do_fetch builtin/fetch.c:1659 #16 0x55f23dca6767 in fetch_one builtin/fetch.c:2133 #17 0x55f23dca6767 in cmd_fetch builtin/fetch.c:2432 #18 0x55f23dba7764 in run_builtin git.c:484 #19 0x55f23dba7764 in handle_builtin git.c:741 #20 0x55f23dbab61e in run_argv git.c:805 #21 0x55f23dbab61e in cmd_main git.c:1000 #22 0x55f23dba4781 in main common-main.c:64 #23 0x7fa0f063fc89 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #24 0x7fa0f063fd44 in __libc_start_main_impl ../csu/libc-start.c:360 #25 0x55f23dba6ad0 in _start (git+0xadfad0) (BuildId: 803b2b7f59beb03d7849fb8294a8e2145dd4aa27) While it is somewhat awkward that the maintenance processes survive tests in the first place, it is totally expected that reftables should work alright with concurrent writers. Seemingly they don't. The only underlying resource that we need to care about in this context is the reftable reader, which is responsible for reading a single table from disk. These readers get discarded immediately (unless reused) when calling `reftable_stack_reload()`, which is wrong. We can only close them once we know that there are no iterators using them anymore. Prepare for a fix by converting the reftable readers to be refcounted. Reported-by: Jeff King <peff@peff.net> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-23reftable/reader: rename `reftable_new_reader()`Patrick Steinhardt2-4/+4
Rename the `reftable_new_reader()` function to `reftable_reader_new()` to match our coding guidelines. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22diff-index: integrate with the sparse indexDerrick Stolee1-3/+12
The sparse index allows focusing the index data structure on the files present in the sparse-checkout, leaving only tree entries for directories not within the sparse-checkout. Each builtin needs a repository setting to indicate that it has been tested with the sparse index before Git will allow the index to be loaded into memory in its sparse form. This is a safety precaution. There are still some builtins that haven't been integrated due to the complexity of the integration and the lack of significant use. However, 'git diff-index' was neglected only because of initial data showing low usage. The diff machinery was already integrated and there is no more work to be done there but add some tests to be sure 'git diff-index' behaves as expected. For this purpose, we can follow the testing pattern used in 51ba65b5c35 (diff: enable and test the sparse index, 2021-12-06). One difference here is that we only verify that the sparse index case agrees with the full index case, but do not generate the expected output. The 'git diff' tests use the '--name-status' option to ease the creation of the expected output, but that's not an option for 'diff-index'. Since the underlying diff machinery is the same, a simple comparison is sufficient to give some coverage. Signed-off-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22transport: fix leaking negotiation tipsPatrick Steinhardt1-0/+1
We do not free negotiation tips in the transport's smart options. Fix this by freeing them on disconnect. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22builtin/fetch: fix leaking transaction with `--atomic`Patrick Steinhardt1-0/+1
With the `--atomic` flag, we use a single ref transaction to commit all ref updates in git-fetch(1). The lifetime of transactions is somewhat weird: while `ref_transaction_abort()` will free the transaction, a call to `ref_transaction_commit()` won't. We thus have to manually free the transaction in the successful case. Adapt the code to free the transaction in the exit path to plug the resulting memory leak. As `ref_transaction_abort()` already freed the transaction for us, we have to unset the transaction when we hit that code path to not cause a double free. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22remote: fix leaking peer ref when expanding refmapPatrick Steinhardt4-0/+4
When expanding remote refs via the refspec in `get_expanded_map()`, we first copy the remote ref and then override its peer ref with the expanded name. This may cause a memory leak though in case the peer ref is already set, as this field is being copied by `copy_ref()`, as well. Fix the leak by freeing the peer ref before we re-assign the field. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22remote: fix leaks when matching refspecsPatrick Steinhardt1-0/+1
In `match_explicit()`, we try to match a source ref with a destination ref according to a refspec item. This matching sometimes requires us to allocate a new source spec so that it looks like we expect. And while we in some end up assigning this allocated ref as `peer_ref`, which hands over ownership of it to the caller, in other cases we don't. We neither free it though, causing a memory leak. Fix the leak by creating a common exit path where we can easily free the source ref in case it is allocated and hasn't been handed over to the caller. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22sideband: fix leaks when configuring sideband colorsPatrick Steinhardt1-0/+1
We read a bunch of configs in `use_sideband_colors()` to configure the colors that Git should use. We never free the strings read from the config though, causing memory leaks. Refactor the code to use `git_config_get_string_tmp()` instead, which does not allocate memory. As we throw the strings away after parsing them anyway there is no need to use allocated strings. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22builtin/send-pack: fix leaking refspecsPatrick Steinhardt5-0/+8
We never free data associated with the assembled refspec in git-send-pack(1), causing a memory leak. Fix this. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22transport: fix leaking OID arrays in git:// transport dataPatrick Steinhardt2-0/+2
The transport data for the "git://" protocol contains two OID arrays that we never free, creating a memory leak. Plug them. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22t/helper: fix leaking multi-pack-indices in "read-midx"Patrick Steinhardt3-1/+10
Several of the subcommands of `test-helper read-midx` do not close the MIDX that they have opened, leading to memory leaks. Fix those. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22builtin/archive: fix leaking `OPT_FILENAME()` valuePatrick Steinhardt2-0/+2
The "--output" switch is an `OPT_FILENAME()` option, which allocates memory when specified by the user. But while we free the string when executed without the "--remote" switch, we don't otherwise because we return via a separate exit path that doesn't know to free it. Fix this by creating a common exit path. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22builtin/merge-tree: fix leaking `-X` strategy optionsPatrick Steinhardt1-0/+1
The `-X` switch for git-merge-tree(1) will push each option into a local `xopts` vector that we then end up parsing. The vector never gets freed though, causing a memory leak. Plug it. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22pretty: fix leaking key/value separator bufferPatrick Steinhardt1-0/+2
The `format_set_trailers_options()` function is responsible for parsing a custom pretty format for trailers. It puts the parsed options into a `struct process_trailer_options` structure, while the allocated memory required for this will be put into separate caller-provided arguments. It is thus the caller's responsibility to free the memory not via the options structure, but via the other parameters. While we do this alright for the separator and filter keys, we do not free the memory associated with the key/value separator. Fix this to plug this memory leak. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22convert: fix leaks when resetting attributesPatrick Steinhardt1-0/+1
When resetting parsed gitattributes, we free the list of convert drivers parsed from the config. We only free some of the drivers' fields though and thus have memory leaks. Fix this by freeing all allocated convert driver fields to plug these memory leaks. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22mailinfo: fix leaking header dataPatrick Steinhardt1-0/+1
We populate the `mailinfo` arrays `p_hdr_data` and `s_hdr_data` with data parsed from the mail headers. These arrays may end up being only partially populated with gaps in case some of the headers do not parse properly. This causes memory leaks because `strbuf_list_free()` will stop iterating once it hits the first `NULL` pointer in the backing array. Fix this by open-coding a variant of `strbuf_list_free()` that knows to iterate through all headers. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22reftable/generic: drop interfacePatrick Steinhardt1-1/+0
The `reftable_table` interface provides a generic infrastructure that can abstract away whether the underlying table is a single table, or a merged table. This abstraction can make it rather hard to reason about the code. We didn't ever use it to implement the reftable backend, and with the preceding patches in this patch series we in fact don't use it at all anymore. Furthermore, it became somewhat useless with the recent refactorings that made it possible to seek reftable iterators multiple times, as these now provide generic access to tables for us. The interface is thus redundant and only brings unnecessary complexity with it. Remove the `struct reftable_table` interface and its associated functions. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22t/helper: refactor to not use `struct reftable_table`Patrick Steinhardt1-15/+18
The `struct reftable_table` interface in our "reftable" test helper gets used such that we can easily print either a single table, or a merged stack. This generic interface is about to go away. Prepare the code for this change by using merged tables instead. When printing the stack we've already got one. When using a single table, we can create a merged table from it to adapt. This removes the last user of the generic interface. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22t/helper: use `hash_to_hex_algop()` to print hashesPatrick Steinhardt1-37/+11
The "reftable" test helper uses a hand-crafted version to convert from a raw hash to its hex variant. This was done because this code used to be part of the reftable library, where we do not use most functions from the Git core. Now that the code is integrated into the "dump-reftable" helper though, that limitation went away. Let's thus use `hash_to_hex_algop()` instead. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22t/helper: inline printing of reftable recordsPatrick Steinhardt1-8/+69
Move printing of reftable records into the "dump-reftable" helper. This follows the same reasoning as the preceding commit. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22t/helper: inline `reftable_table_print()`Patrick Steinhardt1-2/+50
Move `reftable_table_print()` into the "dump-reftable" helper. This follows the same reasoning as the preceding commit. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22t/helper: inline `reftable_stack_print_directory()`Patrick Steinhardt1-1/+22
Move `reftable_stack_print_directory()` into the "dump-reftable" helper. This follows the same reasoning as the preceding commit. Note that this requires us to remove the tests for this functionality in `reftable/stack_test.c`. The test does not really add much anyway, because all it verifies is that we do not crash or run into an error, and it specifically doesn't check the outputted data. Also, as the code is now part of the test helper, it doesn't make much sense to have a unit test for it in the first place. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22t/helper: inline `reftable_reader_print_file()`Patrick Steinhardt1-1/+22
Move `reftable_reader_print_file()` into the "dump-reftable" helper. This follows the same reasoning as the preceding commit. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22t/helper: inline `reftable_dump_main()`Patrick Steinhardt1-1/+60
The printing functionality part of `reftable/dump.c` is really only used by our "dump-reftable" test helper. It is certainly not generic logic that is useful to anybody outside of Git, and the format it generates is quite specific. Still, parts of it are used in our test suite and the output may be useful to take a peek into reftable stacks, tables and blocks. So while it does not make sense to expose this as part of the reftable library, it does make sense to keep it around. Inline the `reftable_dump_main()` function into the "dump-reftable" test helper. This clarifies that its format is subject to change and not part of our public interface. Furthermore, this allows us to iterate on the implementation in subsequent patches. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22reftable/merged: stop using generic tables in the merged tablePatrick Steinhardt1-12/+4
The merged table provides access to a reftable stack by merging the contents of those tables into a virtual table. These subtables are being tracked via `struct reftable_table`, which is a generic interface for accessing either a single reftable or a merged reftable. So in theory, it would be possible for the merged table to merge together other merged tables. This is somewhat nonsensical though: we only ever set up a merged table over normal reftables, and there is no reason to do otherwise. This generic interface thus makes the code way harder to follow and reason about than really necessary. The abstraction layer may also have an impact on performance, even though the extra set of vtable function calls probably doesn't really matter. Refactor the merged tables to use a `struct reftable_reader` for each of the subtables instead, which gives us direct access to the underlying tables. Adjust names accordingly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-22reftable/merged: rename `reftable_new_merged_table()`Patrick Steinhardt1-4/+4
Rename `reftable_new_merged_table()` to `reftable_merged_table_new()` such that the name matches our coding style. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-21Merge branch 'jk/apply-patch-mode-check-fix'Junio C Hamano1-1/+1
Test fix. * jk/apply-patch-mode-check-fix: t4129: fix racy index when calling chmod after git-add
2024-08-21Merge branch 'ps/bundle-outside-repo-fix'Junio C Hamano1-0/+32
"git bundle unbundle" outside a repository triggered a BUG() unnecessarily, which has been corrected. * ps/bundle-outside-repo-fix: bundle: default to SHA1 when reading bundle headers builtin/bundle: have unbundle check for repo before opening its bundle
2024-08-21builtin/maintenance: fix loose objects task emitting pack hashPatrick Steinhardt1-0/+16
The "loose-objects" maintenance tasks executes git-pack-objects(1) to pack all loose objects into a new packfile. This command ends up printing the hash of the packfile to stdout though, which clutters the output of `git maintenance run`. Fix this issue by disabling stdout of the child process. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-21t7900: exercise detaching via trace2 regionsPatrick Steinhardt1-8/+6
In t7900, we exercise the `--detach` logic by checking whether the command ended up writing anything to its output or not. This supposedly works because we close stdin, stdout and stderr when daemonizing. But one, it breaks on platforms where daemonize is a no-op, like Windows. And second, that git-maintenance(1) outputs anything at all in these tests is a bug in the first place that we'll fix in a subsequent commit. Introduce a new trace2 region around the detach which allows us to more explicitly check whether the detaching logic was executed. This is a much more direct way to exercise the logic, provides a potentially useful signal to tracing logs and also works alright on platforms which do not have the ability to daemonize. Signed-off-by: Patrick Steinhardt <ps@pks.im> [jc: dropped a stale in-code comment from a test] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-21t-reftable-block: add tests for index blocksChandra Pratap1-0/+88
In the current testing setup, block operations are left unexercised for index blocks. Add a test that exercises these operations for index blocks. Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-21t-reftable-block: add tests for obj blocksChandra Pratap1-0/+82
In the current testing setup, block operations are left unexercised for obj blocks. Add a test that exercises these operations for obj blocks. Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-21t-reftable-block: add tests for log blocksChandra Pratap1-2/+91
In the current testing setup, block operations are only exercised for ref blocks. Add another test that exercises these operations for log blocks as well. Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-21t-reftable-block: remove unnecessary variable 'j'Chandra Pratap1-4/+2
Currently, there are two variables for array indices, 'i' and 'j'. The variable 'j' is used only once and can be easily replaced with 'i'. Get rid of 'j' and replace its occurence with 'i'. Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-21t-reftable-block: use xstrfmt() instead of xstrdup()Chandra Pratap1-4/+1
Use xstrfmt() to assign a formatted string to a ref record's refname instead of xstrdup(). This helps save the overhead of a local 'char' buffer as well as makes the test more compact. Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-21t-reftable-block: use block_iter_reset() instead of block_iter_close()Chandra Pratap1-6/+2
block_iter_reset() restores a block iterator to its state at the time of initialization without freeing any memory while block_iter_close() deallocates the memory for the iterator. In the current testing setup, a block iterator is allocated and deallocated for every iteration of a loop, which hurts performance. Improve upon this by using block_iter_reset() at the start of each iteration instead. This has the added benifit of testing block_iter_reset(), which currently remains untested. Similarly, remove reftable_record_release() for a reftable record that is still in use. Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-21t-reftable-block: use reftable_record_key() instead of strbuf_addstr()Chandra Pratap1-2/+1
In the current testing setup, the record key required for many block iterator functions is manually stored in a strbuf struct and then passed to these functions. This is not ideal when there exists a dedicated function to encode a record's key into a strbuf, namely reftable_record_key(). Use this function instead of manual encoding. Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-21t-reftable-block: use reftable_record_equal() instead of check_str()Chandra Pratap1-9/+9
In the current testing setup, operations like read and write for reftable blocks as defined by reftable/block.{c, h} are verified by comparing only the keys of input and output reftable records. This is not ideal because there can exist inequal reftable records with the same key. Use the dedicated function for record comparison, reftable_record_equal(), instead of key-based comparison. Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-21t-reftable-block: release used block readerChandra Pratap1-0/+1
Used block readers must be released using block_reader_release() to prevent the occurence of a memory leak. Make test_block_read_write() conform to this statement. Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-21t: harmonize t-reftable-block.c with coding guidelinesChandra Pratap1-26/+26
Harmonize the newly ported test unit-tests/t-reftable-block.c with the following guidelines: - Single line 'for' statements must omit curly braces. - Structs must be 0-initialized with '= { 0 }' instead of '= { NULL }'. - Array sizes and indices should preferably be of type 'size_t'and not 'int'. - Return code variable should preferably be named 'ret', not 'n'. Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-21t: move reftable/block_test.c to the unit testing frameworkChandra Pratap2-1/+120
reftable/block_test.c exercises the functions defined in reftable/block.{c, h}. Migrate reftable/block_test.c to the unit testing framework. Migration involves refactoring the tests to use the unit testing framework instead of reftable's test framework and renaming the tests to follow the unit-tests' naming conventions. Mentored-by: Patrick Steinhardt <ps@pks.im> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Chandra Pratap <chandrapratap3519@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-21rebase --exec: respect --quietMatheus Tavares1-0/+6
rebase --exec doesn't obey --quiet and ends up printing messages about the command being executed: git rebase HEAD~3 --quiet --exec true Executing: true Executing: true Executing: true Let's fix that by omitting the "Executing" messages when using --quiet. Furthermore, the sequencer code includes a few calls to term_clear_line(), which prints a special character sequence to erase the previous line displayed on stderr (even when nothing was printed yet). For an user running the command interactively, the net effect of calling this function with or without --quiet is the same as the characters are invisible in the terminal. However, when redirecting the output to a file or piping to another command, the presence of these invisible characters is noticeable, and it may break user expectation as --quiet is not being respected. We could skip the term_clear_line() calls when --quiet is used, like we are doing with the "Executing" messages, but it makes much more sense to condition the line cleaning upon stderr being TTY, since these characters are really only useful for TTY outputs. The added test checks for both these two changes. Reported-by: Lincoln Yuji <lincolnyuji@hotmail.com> Reported-by: Rodrigo Siqueira <siqueirajordao@riseup.net> Signed-off-by: Matheus Tavares <matheus.tavb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-20Merge branch 'ps/leakfixes-part-4' into ps/leakfixes-part-5Junio C Hamano32-1/+38
* ps/leakfixes-part-4: (22 commits) builtin/diff: free symmetric diff members diff: free state populated via options builtin/log: fix leak when showing converted blob contents userdiff: fix leaking memory for configured diff drivers builtin/format-patch: fix various trivial memory leaks diff: fix leak when parsing invalid ignore regex option unpack-trees: clear index when not propagating it sequencer: release todo list on error paths merge-ort: unconditionally release attributes index builtin/fast-export: plug leaking tag names builtin/fast-export: fix leaking diff options builtin/fast-import: plug trivial memory leaks builtin/notes: fix leaking `struct notes_tree` when merging notes builtin/rebase: fix leaking `commit.gpgsign` value config: fix leaking comment character config submodule-config: fix leaking name entry when traversing submodules read-cache: fix leaking hashfile when writing index fails bulk-checkin: fix leaking state TODO object-name: fix leaking symlink paths in object context object-file: fix memory leak when reading corrupted headers ...
2024-08-20t: migrate t0110-urlmatch-normalization to the new frameworkGhanshyam Thakkar17-260/+271
helper/test-urlmatch-normalization along with t0110-urlmatch-normalization test the `url_normalize()` function from 'urlmatch.h'. Migrate them to the unit testing framework for better performance. And also add different test_msg()s for better debugging. In the migration, last two of the checks from `t_url_general_escape()` were slightly changed compared to the shell script. This involves changing '\'' -> ' '\!' -> ! in the urls of those checks. This is because in C strings, we don't need to escape "'" and "!". Other than these two, all the urls were pasted verbatim from the shell script. Another change is the removal of a MINGW prerequisite from one of the test. It was there because[1] on Windows, the command line is a Unicode string, it is not possible to pass arbitrary bytes to a program. But in unit tests we don't have this limitation. And since we can construct strings with arbitrary bytes in C, let's also remove the test files which contain URLs with arbitrary bytes in the 't/t0110' directory and instead embed those URLs in the unit test code itself. [1]: https://lore.kernel.org/git/53CAC8EF.6020707@gmail.com/ Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Ghanshyam Thakkar <shyamthakkar001@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-20t-hashmap: stop calling setup() for t_intern() testJeff King1-3/+2
Commit f24a9b78a9 (t-hashmap: mark unused parameters in callback function, 2024-08-17) noted that the t_intern() does not need its hashmap parameter, but we have to keep it to conform to the function pointer interface of setup(). But since the only thing setup() does is create and tear down the hashmap, we can just skip calling setup() entirely for this case, and drop the unused parameters. This simplifies the code a bit. Helped-by: Ghanshyam Thakkar <shyamthakkar001@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-19Merge branch 'ps/transport-leakfix-test-updates'Junio C Hamano4-0/+7
Test updates. * ps/transport-leakfix-test-updates: transport: mark more tests leak-free
2024-08-19Merge branch 'tb/incremental-midx-part-1'Junio C Hamano13-82/+132
Incremental updates of multi-pack index files. * tb/incremental-midx-part-1: midx: implement support for writing incremental MIDX chains t/t5313-pack-bounds-checks.sh: prepare for sub-directories t: retire 'GIT_TEST_MULTI_PACK_INDEX_WRITE_BITMAP' midx: implement verification support for incremental MIDXs midx: support reading incremental MIDX chains midx: teach `midx_fanout_add_midx_fanout()` about incremental MIDXs midx: teach `midx_preferred_pack()` about incremental MIDXs midx: teach `midx_contains_pack()` about incremental MIDXs midx: remove unused `midx_locate_pack()` midx: teach `fill_midx_entry()` about incremental MIDXs midx: teach `nth_midxed_offset()` about incremental MIDXs midx: teach `bsearch_midx()` about incremental MIDXs midx: introduce `bsearch_one_midx()` midx: teach `nth_bitmapped_pack()` about incremental MIDXs midx: teach `nth_midxed_object_oid()` about incremental MIDXs midx: teach `prepare_midx_pack()` about incremental MIDXs midx: teach `nth_midxed_pack_int_id()` about incremental MIDXs midx: add new fields for incremental MIDX chains Documentation: describe incremental MIDX format
2024-08-19Merge branch 'jc/tests-no-useless-tee'Junio C Hamano2-3/+3
Test fixes. * jc/tests-no-useless-tee: tests: drop use of 'tee' that hides exit status
2024-08-19Merge branch 'rs/unit-tests-test-run'Junio C Hamano7-369/+430
Unit-test framework has learned a simple control structure to allow embedding test statements in-line instead of having to create a new function to contain them. * rs/unit-tests-test-run: t-strvec: use if_test t-reftable-basics: use if_test t-ctype: use if_test unit-tests: add if_test unit-tests: show location of checks outside of tests t0080: use here-doc test body
2024-08-19t7900: fix flaky test due to leaking background jobPatrick Steinhardt1-2/+7
One of the recently-added tests in t7900 exercises git-maintanance(1) with the `--detach` flag, which causes it to perform maintenance in the background. We do not wait for the backgrounded process to exit though, which causes the process to leak outside of the test, leading to racy behaviour. Fix this by synchronizing with the process via a separate file descriptor. This is the same workaround as we use in t6500, see the function `run_and_wait_for_auto_gc ()`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-17send-email: teach git send-email option to translate aliasesJacob Keller1-0/+104
git send-email has support for converting shorthand alias names to canonical email addresses via the alias file. It supports a wide variety of alias file formats based on popular email program file formats. Other programs, such as b4, would like the ability to convert aliases in the same way as git send-email without needing to re-implement the logic for understanding the many file formats. Teach git send-email a new option, --translate-aliases, which will enable this functionality. Similar to --dump-aliases, this option works like a new mode of operation for git send-email. When run with --translate-aliases, git send-email reads from standard input and converts any provided alias into its canonical name and email according to the alias file. Each expanded name and address is printed to standard output, one per line. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-17test-mergesort: mark unused parameters in trivial callbackJeff King1-1/+1
The mode_copy() function does nothing, but since it's used as a function pointer within "struct mode", it has to conform to the interface. Mark it to quiet -Wunused-parameter. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-17t-hashmap: mark unused parameters in callback functionJeff King1-1/+2
The t_intern() setup function doesn't operate on a hashmap, so it ignores its parameters. But we can't drop them since it is passed as a pointer to setup(), so we have to match the other setup functions. Mark them to silence -Wunused-parameter. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-17reftable: mark unused parameters in virtual functionsJeff King1-1/+1
The reftable code uses a lot of virtual function pointers, but many of the concrete implementations do not need all of the parameters. For the most part these are obviously fine to just mark as UNUSED (e.g., the empty_iterator functions unsurprisingly do not do anything). Here are a few cases where I dug a little deeper (but still ended up just marking them UNUSED): - the iterator exclude_patterns is best-effort and optional (though it would be nice to support in the long run as an optimization) - ignoring the ref_store in many transaction functions is unexpected, but works because the ref_transaction itself carries enough information to do what we need. - ignoring "err" for in some cases (e.g., transaction abort) is OK because we do not return any errors. It is a little odd for reftable_be_create_reflog(), though, since we do return errors there. We should perhaps be creating string error messages at this layer, but I've punted on that for now. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-17unit-tests: ignore unused argc/argvJeff King13-13/+13
All of the unit test programs have their own cmd_main() function, but none of them actually look at the argc/argv that is passed in. In the long run we may want them to handle options for the test harness. But we'd probably do that with a shared harness cmd_main(), dispatching to the individual tests. In the meantime, let's annotate the unused parameters to avoid triggering -Wunused-parameter. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-08-17t/helper: mark more unused argv/argc argumentsJeff King2-2/+2
This is a continuation of 126e3b3d2a (t/helper: mark unused argv/argc arguments, 2023-03-28) to cover a few new cases: - test-example-tap was added since that commit - test-hashmap used to accept the "ignorecase" argument on the command line. But since most of its logic was moved to a unit-test in 3469a23659 (t: port helper/test-hashmap.c to unit-tests/t-hashmap.c, 2024-08-03), it now ignores its argv entirely. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>