summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
3 daysMerge branch 'en/midx-missing-pack-fallback'Junio C Hamano4-1/+123
The object lookup machinery has been taught to gracefully recover when a multi-pack-index points to an owning pack that was removed during a concurrent geometric repack, and 'git replay' has been fixed to not segfault when reading such missing objects. * en/midx-missing-pack-fallback: packfile: recover when a multi-pack-index names a removed pack mktree: do not use OBJECT_INFO_QUICK when checking objects mktree: plug per-tree leak in --batch mode replay: fail gracefully when a merge input is unreadable
3 daysMerge branch 'jk/rev-info-argv-to-free'Junio C Hamano1-0/+17
The memory ownership of argv elements passed to the revision machinery has been made more robust by keeping logically "freed" elements alive until the rev_info struct is released, preventing use-after-free bugs when options store references to them. * jk/rev-info-argv-to-free: revision: simplify mark_argv_for_free() callers revision: hang on to "freed" argv elements
3 daysMerge branch 'tc/replay-linearize'Junio C Hamano1-1/+108
The 'git replay' command has been taught the '--linearize' option to drop merge commits and linearize the replayed history, mimicking 'git rebase --no-rebase-merges'. * tc/replay-linearize: replay: offer an option to linearize the commit topology replay: resolve the replay base outside pick_regular_commit() replay: add helper to put entry into replayed_commits
3 daysMerge branch 'hk/typofix'Junio C Hamano1-1/+1
Various spelling mistakes in comments and test descriptions have been corrected. * hk/typofix: versioncmp: fix typo in versioncmp.c, t/t0022-crlf-rename.sh
3 daysMerge branch 'rs/worktree-add-basename-fixes'Junio C Hamano1-0/+17
The string extraction logic for the branch name and worktree name from the given path in 'git worktree add' has been corrected and simplified to avoid out-of-bounds reads and improper handling of trailing slashes. * rs/worktree-add-basename-fixes: worktree add: let worktree_basename() return string copy worktree add: trim slashes when deriving branch name from path worktree add: reject separator-only path worktree add: don't read out of bounds in worktree_basename()
3 daysMerge branch 'ns/ref-symref-additional-tests'Junio C Hamano2-3/+18
A few tests for the reference handling subsystem have been added to exercise the handling of forbidden characters and symbolic references. * ns/ref-symref-additional-tests: t1402: test forbidden characters in refnames t1401: check symbolic-ref failure and --quiet silence on a non-symbolic ref
6 daysMerge branch 'yn/worktree-repair-relative'Junio C Hamano1-12/+42
The git worktree repair command failed to rewrite the .git file of a working tree from a relative path to an absolute path when the command was run in the working tree itself. The read_gitfile_gently() function was modified to also return whether the path originally recorded in the file was absolute, and this new capability is used to correctly detect such mismatches. * yn/worktree-repair-relative: worktree repair: detect relative path in .git file correctly
6 daysMerge branch 'gr/add-e-use-apply-api'Junio C Hamano1-0/+10
The application of the edited patch in 'git add -e' has been refactored to use the internal apply API directly, avoiding the need to spawn a 'git apply' subprocess. * gr/add-e-use-apply-api: builtin/add.c: replace run_command() with direct apply_all_patches() call
6 daysMerge branch 'jc/you-still-use-that'Junio C Hamano2-2/+2
The instructions for deprecated commands emitted by you_still_use_that() have been reworded to clarify that the removal decision is final and to provide more assertive guidance on finding a replacement. * jc/you-still-use-that: you_still_use_that(): reword the instructions
6 daysMerge branch 'yn/worktree-ambiguous-remote-advice'Junio C Hamano1-2/+15
'git checkout' and 'git worktree add' makes guesses based on a name of a remote-tracking branch, but does not give an error when such a remote-tracking branch cannot be uniquely identified, which has been corrected. * yn/worktree-ambiguous-remote-advice: worktree add: treat multiple matches with --guess-remote as an error worktree add: improve message for ambiguous remote branch name checkout: improve message for ambiguous remote branch name checkout: extract function to display advice for ambiguous remotes
6 daysMerge branch 'kn/reftable-optimize-reloading'Junio C Hamano1-39/+60
The reftable code has been optimized to avoid an unnecessary stat/reload of the stack when an addition already holds the list_file lock, reducing the number of newfstatat syscalls from linear to constant when writing refs. * kn/reftable-optimize-reloading: reftable/stack: avoid reloading the stack when already locked reftable/stack: move list lock to `struct reftable_stack` reftable/stack: rename reftable_stack_new_addition() reftable/stack: remove `REFTABLE_STACK_NEW_ADDITION_RELOAD`
12 daysrevision: hang on to "freed" argv elementsJeff King1-0/+17
In setup_revisions() we rewrite the incoming argv array, losing references to the strings it contains. For a synthetic argv array constructed from heap strings, that traditionally meant we leaked those allocated strings. We fixed the leak in cd43948798 (revision: manage memory ownership of argv in setup_revisions(), 2025-09-19). Now callers can tell the revision code that argv entries are allocated and should be freed, which it will do before overwriting them. But this introduced a new bug! The overwritten entries go away as soon as option parsing is finished, but a few options may actually create new references to those strings. And once we free the strings, those stale references become use-after-free bugs. For example, running: git stash show --src-prefix=foo/ demonstrates the problem: 1. The stash command generates its own synthetic argv (because it has to treat the stash specifiers specially) which it then passes to setup_revisions(). 2. Parsing will create a reference to the partial string "foo/" in revs.diffopt.a_prefix. 3. When setup_revisions() finishes, we rewrite argv to throw away parsed strings. This frees the entry holding "--src-prefix=foo", at which point we have a dangling reference in revs.diffopt. 4. We generate an actual diff, accessing garbage memory via revs.diffopt.a_prefix. The output is usually garbled, but ASan also detects this reliably. One obvious fix here is to allocate new strings when we pull data out of the argv array. But doing so is error prone (every string option must remember to do it or risk a subtle bug), and creates more questions about memory ownership (e.g., some callers assign string literals directly to a_prefix, and we would not want to free those). Instead we can fix this centrally by delaying the free() calls. We'll collect any "freed" strings in a new array, hold on to it for the life of the rev_info struct, and then release it at the end. We can easily use a strvec for this, since it handles growth and cleanup for us. This fixes the prefix case above (which is now tested in t3903), and should fix any other stray cases. Though I could not find any; we use OPT_STRING only in the prefix diff options, and very few revision opts store strings. Those that do (like --format and --encoding) already make a copy of the string. They do not need for us to hold on to the memory longer, but it does not hurt them if we do. One may note that combined with cd43948798 we have approached a simpler solution in a roundabout way. We are still hacking up argv, but now carefully constructing a parallel argv of old strings we've overwritten (and will eventually free). In an alternate universe, we could instead leave the original argv pristine and return a new reduced-size argv. This is conceptually simpler, though it does mean that every caller must free that new argv array itself (not the entries). That's not something they traditionally had to do, so it would mean tweaking every caller. So even though the combination of this cd43948798 and this patch is a little convoluted, it should make things just work (no leaks and no use-after-free) without modifying any callers. Reported-by: Nicolas Le Cam <niko.lecam@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
12 daysversioncmp: fix typo in versioncmp.c, t/t0022-crlf-rename.shHardik Kumar1-1/+1
The patch fixes two typos in two places. versioncmp.c: "fractionnal" -> "fractional" t/t0022-crlf-rename.sh: "similiarity" -> "similarity" No functional changes, only update a comment and a test_description. Signed-off-by: Hardik Kumar <hardikxk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
13 daysreplay: offer an option to linearize the commit topologyToon Claes1-1/+108
One of the stated goals of git-replay(1) is to allow implementing the git-rebase(1) functionality on the server side. The default mode of git-rebase(1) is to act as if `--no-rebase-merges` was given. This mode drops merge commits instead of replaying them, and linearizes the history into a sequence of regular (single-parent) commits. Add option `--linearize` to git-replay(1) to do the same. Each replayed commit is stacked on top of the previously replayed one. When a merge is encountered, the commits reachable from all of its sides are replayed into the single line and the merge itself is dropped. If a ref was pointing to a merge commit, that ref is updated to the merge's last replayed ancestor. git-replay(1) accepts multiple branches, for example: $ git replay --onto main topic1 topic2 Without `--linearize` this replays 'topic1' and 'topic2' onto 'main' (keeping shared portions of history shared and divergent parts divergent) and updates both refs. Due to current implementation limitations, replaying multiple branches with `--linearize` is disallowed to avoid concatenating unrelated histories into a single line. For the same reason disallow the use of `--contained` with `--linearize`. Users who want to linearize multiple branches are advised to do this in separate git-replay(1) invocations. Linearizing multiple branches at once might be added later. Note that `--linearize` is not modeled after git-rebase(1)'s `--rebase-merges[=<mode>]` interface. Recreating merges, by preserving their topology, is a distinct operation that would be a separate mode. `--linearize` only drops merges and replays commits linearly. So git-replay(1) uses its own option rather than reusing that interface. Based-on-patches-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Toon Claes <toon@iotcl.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
13 daysMerge branch 'fr/pack-objects-trace-pack-bytes'Junio C Hamano1-0/+24
The pack-objects command has been updated to record the total bytes written to pack files in trace2 output, allowing performance analysis of different compression settings by comparing the resulting pack sizes. * fr/pack-objects-trace-pack-bytes: pack-objects: trace pack bytes written
13 daysMerge branch 'ps/odb-pluggable-pack-generation'Junio C Hamano1-6/+6
The mechanism to generate a packfile corresponding to the result of a fetch/push has been made pluggable through a set of object database callback functions, removing hardcoded references to 'pack-objects' and enabling alternative ODBs to serve packfiles themselves. * ps/odb-pluggable-pack-generation: bundle: generate packfiles via the object database bundle: get (mostly) rid of `the_repository` builtin/bundle: refactor option handling for progress meter send-pack: generate packfiles via the object database upload-pack: generate packfiles via the object database odb: introduce interface to generate packfiles
13 daysMerge branch 'jt/receive-pack-pluggable-writes'Junio C Hamano1-0/+31
The 'git receive-pack' command has been updated to use a new ODB transaction interface for writing incoming packfiles, making it more backend-agnostic. * jt/receive-pack-pluggable-writes: odb/transaction: add transaction interface to write packfiles odb: return temporary ODB source when set builtin/receive-pack: explicitly pass packfile fd builtin/receive-pack: report unpack errors via strbuf builtin/receive-pack: lift global state out of unpack() builtin/receive-pack: read unpack limit config lazily builtin/receive-pack: pass shallow file explicitly odb/transaction: add transaction finalize interface builtin/receive-pack: properly clean up keep files
13 daysMerge branch 'kh/trailers-no-urls'Junio C Hamano2-0/+71
The trailer parsing machinery has been updated to avoid mistaking lines that begin with a URL (e.g., 'https://...') as trailer lines. This prevents intended textual URLs from being mangled or mistakenly treated as metadata keys. * kh/trailers-no-urls: trailers: stop recognizing URLs as trailers
13 daysMerge branch 'vm/complete-history'Junio C Hamano1-0/+50
The command line completion (in contrib/) has been taught to handle the experimental 'git history' command. * vm/complete-history: completion: complete 'git history split' pathspecs completion: complete 'git history --update-refs' values completion: complete 'git history --empty' values completion: add 'git history' subcommands
13 daysMerge branch 'ps/odb-generic-corrupt-objects'Junio C Hamano3-3/+22
The object database (odb) API has been refactored to distinguish between missing objects and corrupt ones by returning more descriptive error statuses. Both the packed and loose backends now faithfully propagate error details using a generic strbuf error mechanism, removing backend-specific leakage from central lookup paths. * ps/odb-generic-corrupt-objects: odb: handle `OBJECT_INFO_DIE_IF_CORRUPT` generically odb/source: allow `read_object_info()` to bubble up error messages odb/source: let callers discern missing and corrupt objects odb/source: introduce error status when reading objects odb/source-packed: flag known-bad objects as corrupt and not missing
13 daysMerge branch 'yn/worktree-add-no-dwim-with-b'Junio C Hamano1-0/+10
The DWIM logic in 'git worktree add' sometimes tried to infer a remote-tracking branch when an explicit '-b' or '-B' option was given to create a new branch, causing the explicit branch name to be ignored, which has been corrected. * yn/worktree-add-no-dwim-with-b: worktree add: shouldn't dwim if -b or -B is given
13 dayspackfile: recover when a multi-pack-index names a removed packElijah Newren2-1/+41
A geometric repack writes a new pack and multi-pack-index and then deletes the packs the new one subsumes. A process still using the previous MIDX keeps seeing a removed pack listed as the owner of some objects. Since a MIDX attributes each object to exactly one pack, such an object is served only through its recorded owner; if that owner was just removed, find_pack_entry() cannot serve it -- the MIDX lookup routes to the missing pack, and the regular pack fallback deliberately skips every MIDX-covered pack, so a surviving copy in another covered pack (e.g. a kept base pack) is never consulted. Unlike the ordinary "a pack's .idx is mapped but its .pack is gone" race, the second read does not rescue us. Reloading the on-disk pack set does not reload the borrowed, cached MIDX (freeing it under the code that caches the "struct multi_pack_index *" would be a use-after-free), so the stale MIDX keeps routing to the removed pack and the surviving copy stays hidden behind the covered-pack skip. cat-file, rev-list and pack-objects can thus all spuriously fail with "unable to read object". Teach find_pack_entry() to recover. The MIDX lookup now returns a tri-state, distinguishing an object absent from the MIDX from one it owns via a pack that can no longer be opened; in the latter case, once the regular fallback has also missed, scan the MIDX's packs directly for a surviving copy. Because the return value is no longer a boolean, rename fill_midx_entry() to midx_fill_entry() so callers must reckon with the new enum rather than silently treat MIDX_FILL_OWNER_UNAVAILABLE as a hit. Do the scan only on the second read (OBJECT_INFO_SECOND_READ): by then the cheaper on-disk reload has run, so an object merely relocated into a new (uncovered) pack has already been found by the regular fallback, and only a genuine hidden duplicate reaches the rescan. A QUICK caller that skips the second read simply accepts the false negative, as QUICK is designed to. Reloading the stale MIDX would be a more complete fix but is much more involved (the borrowers above need proper invalidation), so leave that for later. Assisted-by: Claude Opus 4.8 & GPT-5.6 Sol Helped-by: Jeff King <peff@peff.net> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
13 daysmktree: do not use OBJECT_INFO_QUICK when checking objectsElijah Newren1-0/+48
mktree_line() checks each referenced object's type with odb_read_object_info_extended() under OBJECT_INFO_QUICK. QUICK skips the reprepare-and-retry that reloads the on-disk pack set, so a resident "git mktree --batch" reader reports an object that a concurrent repack just relocated into a new pack as missing, and rejects the entry. QUICK entered this lookup in 817b0f602710 (mktree: do not check type of remote objects, 2022-06-21) only to avoid lazily fetching promisor objects; OBJECT_INFO_SKIP_FETCH_OBJECT already provides that. Drop OBJECT_INFO_QUICK and keep OBJECT_INFO_SKIP_FETCH_OBJECT, so mktree still avoids a promisor fetch but recovers an object that was merely repacked. Add a regression test driving a resident mktree --batch reader across a concurrent repack that retires a pack. Assisted-by: Claude Opus 4.8 & GPT-5.6 Sol Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
13 daysreplay: fail gracefully when a merge input is unreadableElijah Newren1-0/+34
When objects involved in the merge cannot be read, the merge machinery will return early with result.clean = -1, and result.tree left as NULL. pick_regular_commit() tested only "if (!result->clean)", ignoring the case where "clean < 0". That causes the code to try to use result->tree, resulting in a SIGSEGV. Handle clean < 0 explicitly; the merge machinery will already have printed messages such as "Could not read <object>" and "collecting merge info failed for trees...", so we don't need to add much detail beyond the fact that the merge failed. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-08-28Merge branch 'sk/object-name-use-after-free'Junio C Hamano1-0/+11
A heap-use-after-free bug in the object name parsing code when reporting failures with a relative path to a sparse directory has been corrected. * sk/object-name-use-after-free: object-name: avoid use-after-free in get_oid_with_context_1()
2026-08-28worktree repair: detect relative path in .git file correctlyYoichi NAKAYAMA1-12/+42
Given a state in which the cross-references between the worktree and the repository (specifically worktree/id/gitdir in the main repository and the .git file in the worktree) are recorded using absolute paths, setting 'worktree.useRelativePaths=true' and running 'git worktree repair' within the main worktree converts them to relative paths. Conversely, given a state in which the cross-references are recorded using relative paths, one would expect that setting 'worktree.useRelativePaths=false' and running 'git worktree repair' would convert them to absolute paths. However, they remain as relative paths. This is because we incorrectly use read_gitfile_gently(), which always returns an absolute path. To fix this, introduce read_gitfile_raw(), which reads the path from the .git file without resolving it to an absolute path. Because read_gitfile_raw() does not validate the path with is_git_directory(), repair_gitfile() performs this validation to preserve the existing behavior. Signed-off-by: Yoichi NAKAYAMA <yoichi.nakayama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-08-27you_still_use_that(): reword the instructionsJunio C Hamano2-2/+2
The message is overly long and may mislead readers into thinking there is recourse other than adopting the new workflow. Clarify that the message is there merely to help them find a replacement workflow, and is not offering to reconsider a decision that has already taken effect. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-08-27worktree add: treat multiple matches with --guess-remote as an errorYoichi NAKAYAMA1-0/+13
When 'git worktree add <path>' is invoked without <commit-ish> and with the --guess-remote option (or when worktree.guessRemote is set to true), it tries to find a remote-tracking branch matching the basename of <path>. Currently, the behavior when multiple matches are found is the same as when no match is found: it falls back to creating a branch from HEAD. This has been the behavior since 71d6682d8c (worktree: add --guess-remote option to add subcommand, 2017-11-29), when the option was first introduced. However, if the specified <path> matches any remote-tracking branch, we infer that the user intended to use one of the remote-tracking branches as the start-point rather than HEAD. So we abort the creation of the branch and worktree when there are multiple matches, and instruct the user to choose the start-point. Signed-off-by: Yoichi NAKAYAMA <yoichi.nakayama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-08-27worktree add: improve message for ambiguous remote branch nameYoichi NAKAYAMA1-2/+2
When the user runs 'git worktree add ../foo-dir bar-topic' without specifying a remote, and there is no local branch named bar-topic, we try to guess which remote branch bar-topic refers to, then create a new branch named bar-topic that tracks the remote branch. If multiple remotes have a branch named bar-topic, we silently gave up, leaving the variable 'branch' intact. We then entered the conditional clause 'if (!opts.orphan && !lookup_commit_reference_by_name(branch))' and triggered an "invalid reference" error. This error message did not provide enough information to resolve the ambiguity. When multiple matching branches are found, display a hint and a descriptive error message and die immediately. Signed-off-by: Yoichi NAKAYAMA <yoichi.nakayama@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-08-26t1402: test forbidden characters in refnamesNikolaus Schuetz1-3/+6
git-check-ref-format(1) documents that a refname cannot contain a space, tilde, caret, colon, question-mark, asterisk, open-bracket or backslash, nor the sequence "..", and cannot be the single character "@". Of these, only "?", "\" and ".." were tested embedded in an otherwise-valid refname; "*" was checked only as a lone character or with --refspec-pattern. Test all of them in that embedded form with a single loop, and check that "@" alone is rejected even with --allow-onelevel -- where "@" is otherwise a valid refname component, as "refs/@" confirms. Signed-off-by: Nikolaus Schuetz <nikolauspschuetz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-08-26t1401: check symbolic-ref failure and --quiet silence on a non-symbolic refNikolaus Schuetz1-0/+12
git-symbolic-ref(1) documents that reading a name that is not a symbolic ref fails, and that --quiet does so silently. Tests such as t2020 and t5621 already rely on "symbolic-ref -q HEAD" failing on a detached HEAD, but none checks that the plain form reports the error or that --quiet stays silent. Assert that a non-symbolic ref fails with the "is not a symbolic ref" message, and that --quiet fails with no output. Use test_must_fail rather than pinning the exact exit codes, which are documented but not worth freezing in the test. Signed-off-by: Nikolaus Schuetz <nikolauspschuetz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-08-25worktree add: trim slashes when deriving branch name from pathRené Scharfe1-0/+13
worktree_basename() sets `n` to the length of `path` without trailing path separators, not to the length of the basename. This matters when deriving a branch name from a path with more than one component. E.g.: path: /new/worktree/ s: ^ n: |-----------| So here xstrndup(s, n) copies up to 13 characters from "worktree/", effectively to the end of the string, including the trailing dash. Path separators are not allowed at the end of branch names, so strip them off by calculating the basename length and extracting just that part. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-08-25worktree add: reject separator-only pathRené Scharfe1-0/+4
worktree_basename() extracts an empty basename from a path consisting only of zero or more path separators. We can't use that as a worktree name. Properly report such a path as invalid instead of triggering a BUG that asks the user what just happened. Original-patch-by: Matthias Aßhauer <mha1993@live.de> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-08-25Merge branch 'jc/complete-checkout'Junio C Hamano1-0/+56
'git -C <dir> checkout fi<TAB>' did not complete, which has been corrected. * jc/complete-checkout: completion: 'git checkout' completes untracked paths as a last resort completion: complete tracked paths for "git checkout" completion: no-op refactoring of checkout completion
2026-08-25Merge branch 'jc/complete-diff-tracked-paths'Junio C Hamano1-0/+58
'git -C <dir> diff fi<TAB>' did not complete 'file', which has been corrected. * jc/complete-diff-tracked-paths: completion: 'git diff' completes untracked paths as a last resort completion: complete tracked paths for 'git diff' completion: no-op refactoring of diff completion
2026-08-25Merge branch 'js/packfile-fast-append'Junio C Hamano1-0/+4
The performance of adding numerous new packfiles has been improved by introducing a fast path for known-new packfiles to skip an unnecessary traversal in packfile_list_append(), avoiding a quadratic complexity regression on load. * js/packfile-fast-append: packfile: fix perf regression with many packs
2026-08-25Merge branch 'ss/repack-drop-filtered'Junio C Hamano2-0/+186
'git repack' has been taught '--drop-filtered' to delete local promisor blobs exceeding a limit (currently 'blob:limit=') in partial clones, reclaiming space. Guards prevent running during other operations or if referenced by the index. * ss/repack-drop-filtered: builtin/repack: add guards for --drop-filtered builtin/repack: actually drop filtered promisor blobs builtin/repack: enumerate promisor blobs for --drop-filtered repack-promisor: allow excluding objects from the rebuilt promisor pack list-objects-filter: add list_objects_filter__filter_oidset() builtin/repack: add --drop-filtered and --dry-run options
2026-08-24Merge branch 'ps/t7900-deflake-maintenance'Junio C Hamano1-30/+46
Various tests in 't7900-maintenance.sh' have been updated to use a throwaway repository, and auto-detaching of maintenance tasks is now disabled for these tests to fix flaky races with concurrent background maintenance jobs. * ps/t7900-deflake-maintenance: t7900: fix flaky "maintenance.strategy" test t7900: adapt some tests to use a throwaway repository
2026-08-24Merge branch 'en/serve-promisor-remote-fix'Junio C Hamano1-0/+11
A client requesting the promisor-remote capability without a value caused a null pointer dereference, which has been corrected by rejecting a request without an argument. * en/serve-promisor-remote-fix: serve: reject valueless promisor-remote capability
2026-08-24Merge branch 'js/pack-objects-delta-size-t'Junio C Hamano2-4/+5
The 'pack-objects' and delta-encoding code paths have been updated to use 'size_t' instead of 'unsigned long' for object sizes and offset limits, avoiding potential truncation issues on 64-bit Windows. * js/pack-objects-delta-size-t: packfile: widen `unpack_object_header_buffer()` to `size_t` git-zlib: widen `git_deflate_bound()` to `size_t` t/helper/test-pack-deltas: widen `do_compress()`'s maxsize local to `size_t` http-push: widen `start_put()`'s size local from `ssize_t` to `size_t` diff: widen `deflate_it()`'s bound local from int to `size_t` archive-zip: widen `zlib_deflate_raw()`'s maxsize local to `size_t` packfile, git-zlib: widen `use_pack()` and zstream avail fields to `size_t` delta: widen `create_delta()` and `diff_delta()` to `size_t` pack-objects: widen `mem_usage` and `try_delta()`'s out-param to `size_t` pack-objects: widen `free_unpacked()` return to `size_t` pack-objects: widen delta-cache accounting to `size_t` delta: widen `create_delta_index()` parameter to `size_t` diff-delta: widen `struct delta_index`' size fields to `size_t`
2026-08-24Merge branch 'cc/git-shallow-file-wo-value'Junio C Hamano1-0/+7
The '--shallow-file' option of 'git' command requires a value, but the code did not check the presence of a value and instead segfaulted without one, which has been corrected. * cc/git-shallow-file-wo-value: git: avoid segfault on "git --shallow-file" without a value
2026-08-24Merge branch 'js/coverity-unchecked-returns-fix'Junio C Hamano1-2/+4
A handful of code paths have been corrected to check return values from functions like curl_easy_duphandle(), deflateInit(), lseek(), dup(), and strbuf_getline_lf(), resolving several Coverity warnings about unchecked returns. * js/coverity-unchecked-returns-fix: bisect: handle dup() failure when redirecting stdout bisect: check get_terms return at all call sites bisect: check strbuf_getline_lf return when reading terms transport-helper: warn when export-marks file cannot be finalized transport-helper: check dup() return in get_exporter compat/pread: check initial lseek for errors last-modified: handle repo_parse_commit() failures reftable tests: check reftable_table_init_ref_iterator() return reftable/block: check deflateInit() return value reftable: handle block-writer initialization errors config: propagate launch_editor() failure in show_editor() http: die on curl_easy_duphandle failure in get_active_slot
2026-08-24reftable/stack: move list lock to `struct reftable_stack`Karthik Nayak1-0/+28
The struct `reftable_addition` is used to modify a given stack, as such, it also includes a `struct reftable_flock` used to obtain the lock to the list file. While the scope of the field lies within this struct, it doesn't allow for optimizations to be made on `struct reftable_stack` itself. Move the field to `struct reftable_stack`, allowing us to make a simple optimization around avoiding a stack reload when we have already obtained a lock. While this is currently possible in the write path, the write path also contains multiple branches to reads which only work on top of `struct reftable_stack`, and we would miss the optimization in such paths. Since the lock is now shared across all additions on the same stack, a second `reftable_addition` that fails to acquire the already held lock would still call `reftable_addition_close()`, which will release the `stack->list_lock` which is still held by the first addition. To avoid this, add a new bit field `locked` to `reftable_addition` that tracks whether a particular addition is the one holding the lock, and only release it in that case. Add a unit test to validate this behavior. While here, remove an unused header file from 'reftable/stack.h'. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-08-24reftable/stack: rename reftable_stack_new_addition()Karthik Nayak1-5/+5
Rename the function `reftable_stack_new_addition()` to `reftable_stack_addition_new()` to be more inline with our naming scheme. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-08-24reftable/stack: remove `REFTABLE_STACK_NEW_ADDITION_RELOAD`Karthik Nayak1-38/+31
In 80e7342ea8 (reftable/stack: allow locking of outdated stacks, 2024-09-24), the `REFTABLE_STACK_NEW_ADDITION_RELOAD` was introduced so that callers of `reftable_stack_init_addition()` can also reload the stack if there was a concurrent update made before the lock was obtained. Then 16684b6fae (refs/reftable: always reload stacks when creating lock, 2025-08-12) updated all of the remaining call-sites to propagate this flag to ensure that we always reload the stack whenever there was a concurrent update. As all calls to `reftable_stack_init_addition()` inevitably propagate the flag, it is safe to remove the flag and its associated code and make the reloading of the stack the default flow. This makes it easier to follow the flow and simplifies the logic. The only exceptions are: 1. Unit tests, where we explicitly do not propagate the flag. These tests are now modified with the new status quo. 2. `reftable_stack_clean()`, which was propagating 0 to `reftable_stack_new_addition()` but was then manually reloading the stack after. Here the new flow will achieve the same, while also allowing us to remove the manual reload. This also makes two checks for 'REFTABLE_OUTDATED_ERROR' redundant, so remove them also. Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-08-23Merge branch 'kk/merge-base-exhaustion'Junio C Hamano4-12/+347
The merge-base computation has been optimized by stopping the walk early when one side's exclusive commits in the queue are exhausted, yielding significant speedups for queries with one-sided histories. * kk/merge-base-exhaustion: commit-reach: remove commit-date ordering fallback commit-reach: move min_generation check into paint_queue_get() commit-reach: terminate merge-base walk when one paint side is exhausted commit-reach: introduce struct paint_state with per-side counters t6600: add clock-skew topologies and step counts for edge cases commit-reach: add trace2 instrumentation to paint_down_to_common() t6099: add side-exhaustion regression test t6600: add test cases for side-exhaustion edge cases test-lib-functions: improve diagnostic output for trace2 data assertions Documentation/technical: add paint-down-to-common doc
2026-08-23Merge branch 'js/sequencer-release-odb-before-commit'Junio C Hamano1-0/+18
The sequencer has been updated to release the object database before spawning 'git commit'. This prevents open file handles from blocking auto-maintenance tasks, such as repacking, on systems like Windows where open files cannot be easily unlinked. * js/sequencer-release-odb-before-commit: sequencer: release the ODB before spawning git commit
2026-08-23Merge branch 'hn/send-email-missing-subject-error'Junio C Hamano1-0/+15
The error message given by 'git send-email' when a message file is missing a 'Subject:' header has been clarified, and the error string is now terminated with a newline so that Perl avoids appending its internal source location data. * hn/send-email-missing-subject-error: send-email: clarify missing subject error
2026-08-23Merge branch 'ps/odb-streams'Junio C Hamano1-17/+20
The 'struct odb_read_stream' and 'struct odb_write_stream' structures have been consolidated into a single unified 'struct odb_stream' structure, simplifying object database streaming APIs and enabling streaming of arbitrary object types. * ps/odb-streams: odb/streaming: unify function names to create new streams odb/streaming: rename `struct input_zstream_data` odb/streaming: rename `struct read_object_fd_data` odb/streaming: consolidate read and write streams odb/streaming: rename `struct odb_read_stream` odb/streaming: support streaming arbitrary object types odb/streaming: drop `is_finished` field odb/streaming: track write stream size in the structure
2026-08-23Merge branch 'cc/fast-import-usage'Junio C Hamano4-2/+35
The usage string of 'git fast-import' has been updated to use the parse_options() API for displaying help, and its SYNOPSIS in the documentation has been standardized to match. * cc/fast-import-usage: fast-import: remove useless from_stream argument fast-import: use parse_options() for command line options fast-import: use callbacks to parse some options fast-import: use struct option for usage string fast-import: move command state globals into 'struct fast_import_state' fast-import: introduce 'struct fast_import_state' fast-import: factor out option_*() functions fast-import: use int for some bool flags fast-import: localize 'i' into the 'for' loops using it api-parse-options.adoc: document hidden and OPT_*_F option macros api-parse-options.adoc: document per-option flags parse-options: introduce OPT_HIDDEN_GROUP