summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-04-13Merge branch 'kh/doc-am-xref'Junio C Hamano1-6/+5
Doc update. * kh/doc-am-xref: doc: am: correct to full --no-message-id doc: am: revert Message-ID trailer claim
2026-04-13gitglossary: fix indentation of sub-listsJeff King1-0/+6
The glossary entry is a list of terms and their definitions, so multi-paragraph definitions need "+" continuation lines to indicate that they are part of a single entry. When an entry contains a sub-list (say, a bulleted list), the final "+" may become ambiguous: is it connecting the next paragraph to the final entry of the sub-list, or to the original list of definition paragraphs? Asciidoc generally connects it to the former, even when we mean the latter, and you end up with the next paragraph indented incorrectly, like this: glob ...defines glob... Two consecutive asterisks ("**") in patterns matched against full pathname may have special meaning: - ...some special meaning of **... - ...another special meaning of **... - Other consecutive asterisks are considered invalid. Glob magic is incompatible with literal magic. That final "Glob magic is incompatible" paragraph is in the wrong spot. It should be at the same level as "Two consecutive asterisks", as it is not part of the final "Other consecutive asterisks" bullet point. The same problem appears in several other spots in the glossary. Usually we'd fix this by using "--" markers, which put the sub-list into its own block. But there's a catch: in some of these spots we are already in an open block, and nesting open blocks is a problem. It seems to work for me using Asciidoc 10.2.1, but Asciidoctor 2.0.26 makes a mess of it (our intent to open a new block seems to close the old one). Fortunately there's a work-around: when using a "+" list-continuation, the number of empty lines above the continuation indicates which level of parent list to continue. So by adding an empty line after our unordered list (before the "+"), we should be able to continue the definition list item. But asciidoc being asciidoc, of course that is not the end of the story. That technique works fine for the "glob" and "attr" lists in this patch, but under the "refs" item it works for only 1 of the 2 lists! I can't figure out why, and this may be an asciidoctor bug. But we can work around it by using "--" open-block markers here, since we're not already in an open block. So using the extra blank line for the first two instances, and "--" markers for the second two, this patch produces identical output from "doc-diff HEAD^ HEAD" for both --asciidoctor and --asciidoc modes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-13CI: bump actions/checkout from 4 to 5 for rust-analysis jobJunio C Hamano1-1/+1
GitHub Actions started complaining about use of Node.js 20 and I was wondering why only one job uses actions/checkout@v4, while everybody else already uses actions/checkout@v5. It turns out that it is caused by a semantic mismerge between e75cd059 (ci: check formatting of our Rust code, 2025-10-15) that added a new use of actions/checkout@v4 that happened very close to another change 63541ed9 (build(deps): bump actions/checkout from 4 to 5, 2025-10-16) that updated all uses of actions/checkout@v4 to use vactions/checkout@v5. Update the leftover and the last use of actions/checkout@v4 to use actions/checkout@v5 to help ourselves to move away from Node.js 20. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-13doc: am: correct to full --no-message-idKristoffer Haugsbakk1-1/+1
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-13doc: am: revert Message-ID trailer claimKristoffer Haugsbakk1-5/+4
I claimed in 3c18135b (doc: am: say that --message-id adds a trailer, 2026-02-09) that `git am --message-id` adds a Git trailer. But that isn’t the case; for the case of a commit message with a subject, body, and no trailer block: <subject> <paragrah> It just appends the line right after `paragraph`: <subject> <paragraph> Message-ID: <message-id_trailer.323@msgid.xyz> It does work for two other cases though, namely subject-only and with an existing trailer block. This is at best an inconsistency and arguably a bug, but we’re at the trailing end of the release cycle now. So reverting the doc is safer than making msg-id act as a trailer, for now. Revert this hunk from commit 3c18135b except the only useful change (“Also use inline-verbatim for `Message-ID`”). Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-10Merge branch 'jc/no-writev-does-not-work'Junio C Hamano11-140/+4
We used writev() in limited code paths and supplied emulation for platforms without working writev(), but the emulation was too faithful to the spec to make the result useless to send even 64kB; revert the topic and plan to restart the effort later. * jc/no-writev-does-not-work: Revert "compat/posix: introduce writev(3p) wrapper" Revert "wrapper: introduce writev(3p) wrappers" Revert "sideband: use writev(3p) to send pktlines" Revert "cmake: use writev(3p) wrapper as needed"
2026-04-10Merge branch 'ps/archive-prefix-doc'Junio C Hamano1-0/+5
Doc update. * ps/archive-prefix-doc: archive: document --prefix handling of absolute and parent paths
2026-04-10Merge branch 'bc/ref-storage-default-doc-update'Junio C Hamano1-3/+8
Doc update. * bc/ref-storage-default-doc-update: docs: correct information about reftable
2026-04-10rust: we are way beyond 2.53Junio C Hamano1-1/+1
Earlier we timelined that we'd tune our build procedures to build with Rust by default in Git 2.53, but we are already in prerelease freeze for 2.54 now. Update the BreakingChanges document to delay it until Git 2.55 (slated for the end of June 2026). Noticed-by: brian m. carlson <sandals@crustytoothpaste.net> Helped-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-10t1800: test SIGPIPE with parallel hooksJeff King1-0/+38
We recently fixed a bug in commit 2226ffaacd (run_processes_parallel(): fix order of sigpipe handling, 2026-04-08) where a hook that caused us to get SIGPIPE would accidentally trigger the run_processes_parallel() cleanup handler killing the child processes. For a single hook, this meant killing the already-exited hook. This case was triggered by our tests, but was only a problem on some platforms. But if you have multiple hooks running in parallel, this causes a problem everywhere, since one hook failing to read its input would take down all hooks. Now that we have parallel hook support, we can add a test for this case. It should pass already, due to the existing fix. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-10hook: allow hook.jobs=-1 to use all available CPU coresAdrian Ratiu4-20/+108
Allow -1 as a value for hook.jobs, hook.<event>.jobs, and the -j CLI flag to mean "use as many jobs as there are CPU cores", matching the convention used by fetch.parallel and other Git subsystems. The value is resolved to online_cpus() at parse time so the rest of the code always works with a positive resolved count. Other non-positive values (0, -2, etc) are rejected with a warning (config) or die (CLI). Suggested-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-10hook: add hook.<event>.enabled switchAdrian Ratiu7-11/+165
Add a hook.<event>.enabled config key that disables all hooks for a given event, when set to false, acting as a high-level switch above the existing per-hook hook.<friendly-name>.enabled. Event-disabled hooks are shown in "git hook list" with an "event-disabled" tab-separated prefix before the name: $ git hook list test-hook event-disabled hook-1 event-disabled hook-2 With --show-scope: $ git hook list --show-scope test-hook local event-disabled hook-1 When a hook is both per-hook disabled and event-disabled, only "event-disabled" is shown: the event-level switch is the more relevant piece of information, and the per-hook "disabled" status will surface once the event is re-enabled. Using an event name as a friendly-name (e.g. hook.<event>.enabled) can cause ambiguity, so a fatal error is issued when using a known event name and a warning is issued for unknown event name, since a collision cannot be detected with certainty for unknown events. Suggested-by: Patrick Steinhardt <ps@pks.im> Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-10hook: move is_known_hook() to hook.c for wider useAdrian Ratiu5-23/+29
Move is_known_hook() from builtin/hook.c (static) into hook.c and export it via hook.h so it can be reused. Make it return bool and the iterator `h` for clarity (iterate hooks). Both meson.build and the Makefile are updated to reflect that the header is now used by libgit, not the builtin sources. The next commit will use this to reject hook friendly-names that collide with known event names. Co-authored-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-10hook: warn when hook.<friendly-name>.jobs is setAdrian Ratiu2-0/+70
Issue a warning when the user confuses the hook process and event namespaces by setting hook.<friendly-name>.jobs. Detect this by checking whether the name carrying .jobs also has .command, .event, or .parallel configured. Extract is_friendly_name() as a helper for this check, to be reused by future per-event config handling. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-10hook: add per-event jobs configAdrian Ratiu5-5/+123
Add a hook.<event>.jobs count config that allows users to override the global hook.jobs setting for specific hook events. This allows finer-grained control over parallelism on a per-event basis. For example, to run `post-receive` hooks with up to 4 parallel jobs while keeping other events at their global default: [hook] post-receive.jobs = 4 Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-10hook: add -j/--jobs option to git hook runEmily Shaffer4-10/+170
Expose the parallel job count as a command-line flag so callers can request parallelism without relying only on the hook.jobs config. Add tests covering serial/parallel execution and TTY behaviour under -j1 vs -jN. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-10hook: mark non-parallelizable hooksEmily Shaffer8-14/+56
Several hooks are known to be inherently non-parallelizable, so initialize them with RUN_HOOKS_OPT_INIT_FORCE_SERIAL. This pins jobs=1 and overrides any hook.jobs or runtime -j flags. These hooks are: applypatch-msg, pre-commit, prepare-commit-msg, commit-msg, post-commit, post-checkout, and push-to-checkout. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-10hook: allow pre-push parallel executionAdrian Ratiu5-12/+60
pre-push is the only hook that keeps stdout and stderr separate (for backwards compatibility with git-lfs and potentially other users). This prevents parallelizing it because run-command needs stdout_to_stderr=1 to buffer and de-interleave parallel outputs. Since we now default to jobs=1, backwards compatibility is maintained without needing any extension or extra config: when no parallelism is requested, pre-push behaves exactly as before. When the user explicitly opts into parallelism via hook.jobs > 1, hook.<event>.jobs > 1, or -jN, they accept the changed output behavior. Document this and let get_hook_jobs() set stdout_to_stderr=1 automatically when jobs > 1, removing the need for any extension infrastructure. Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-10hook: allow parallel hook executionEmily Shaffer4-6/+253
Hooks always run in sequential order due to the hardcoded jobs == 1 passed to run_process_parallel(). Remove that hardcoding to allow users to run hooks in parallel (opt-in). Users need to decide which hooks to run in parallel, by specifying "parallel = true" in the config, because Git cannot know if their specific hooks are safe to run or not in parallel (for e.g. two hooks might write to the same file or call the same program). Some hooks are unsafe to run in parallel by design: these will marked in the next commit using RUN_HOOKS_OPT_INIT_FORCE_SERIAL. The hook.jobs config specifies the default number of jobs applied to all hooks which have parallelism enabled. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-10hook: parse the hook.jobs configAdrian Ratiu3-2/+28
The hook.jobs config is a global way to set hook parallelization for all hooks, in the sense that it is not per-event nor per-hook. Finer-grained configs will be added in later commits which can override it, for e.g. via a per-event type job options. Next commits will also add to this item's documentation. Parse hook.jobs config key in hook_config_lookup_all() and store its value in hook_all_config_cb.jobs, then transfer it into r->jobs after the config pass completes. This is mostly plumbing and the cached value is not yet used. Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-10config: add a repo_config_get_uint() helperAdrian Ratiu4-0/+51
Next commits add a 'hook.jobs' config option of type 'unsigned int', so add a helper to parse it since the API only supports int and ulong. An alternative is to make 'hook.jobs' an 'int' or parse it as an 'int' then cast it to unsigned, however it's better to use proper helpers for the type. Using 'ulong' is another option which already has helpers, but it's a bit excessive in size for just the jobs number. Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-10repository: fix repo_init() memleak due to missing _clear()Adrian Ratiu1-0/+1
There is an old pre-existing memory leak in repo_init() due to failing to call clear_repository_format() in the error case. It went undetected because a specific bug is required to trigger it: enable a v1 extension in a repository with format v0. Obviously this can only happen in a development environment, so it does not trigger in normal usage, however the memleak is real and needs fixing. Fix it by also calling clear_repository_format() in the error case. Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-10l10n: zh_CN: post-2.53 code reviewJiang Xin1-4/+6
Update Simplified Chinese translation for post-2.53 code review. Reviewed-by: 依云 <lilydjwg@gmail.com> Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2026-04-09Enable Rust by defaultbrian m. carlson6-10/+15
Our breaking changes document says that we'll enable Rust by default in Git 2.54. Adjust the Makefile to switch the option from WITH_RUST to NO_RUST to enable it by default and update the help text accordingly. Similarly, for Meson, enable the option by default and do not automatically disable it if Cargo is missing, since the goal is to help users find where they are likely to have problems in the future. Update our CI tests to swap out the single Linux job with Rust to a single job without, both for Makefile and Meson. Similarly, update the Windows Makefile job to not use Rust, while the Meson job (which does not build with ci/lib.sh) will default to having it enabled. Move the check for Cargo in the Meson build because it is no longer needed in the main script. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-09Linux: link against libdlbrian m. carlson1-0/+1
Older versions of Rust on Linux, such as that used in Debian 11 in our CI, require linking against libdl. Were we linking with Cargo, this would be included automatically, but since we're not, explicitly set it in the system-specific config. This library is part of libc, so linking against it if it happens to be unnecessary will add no dependencies to the resulting binary. In addition, it is provided by both glibc and musl, so it should be portable to almost all Linux systems. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-09ci: install cargo on Alpinebrian m. carlson1-1/+1
We'll make Rust the default in a future commit, so be sure to install Cargo (which will also install Rust) to prepare for that case. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-09docs: update version with default Rust supportbrian m. carlson1-1/+1
We missed the cut-off for Rust by default in 2.53, but we still can enable it by default for 2.54, so update our breaking changes document accordingly. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-09writev: retract the topic until we have a better emulationJunio C Hamano11-140/+4
The emulation layer we added for writev(3p) tries to be too faithful to the spec that on systems with SSIZE_MAX set to lower than 64kB to fit a single sideband packet would fail just like the real system writev(), which makes our use of writev() for sideband messages unworkable. Let's revert them and reboot the effort after the release. The reverted commits are: $ git log -Swritev --oneline 8023abc632^..v2.52.0-rc1 89152af176 cmake: use writev(3p) wrapper as needed 26986f4cba sideband: use writev(3p) to send pktlines 1970fcef93 wrapper: introduce writev(3p) wrappers 3b9b2c2a29 compat/posix: introduce writev(3p) wrapper 8023abc632 is the merge of ps/upload-pack-buffer-more-writes topic to the mainline. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-09Revert "compat/posix: introduce writev(3p) wrapper"Junio C Hamano5-65/+0
This reverts commit 3b9b2c2a29a1d529ca9884fa0a6529f6e2496abe; let's not use writev() for now.
2026-04-09Revert "wrapper: introduce writev(3p) wrappers"Junio C Hamano4-59/+0
This reverts commit 1970fcef93adcc5a35f6468d00a5a634d5af2b3c; let's not use writev() for now.
2026-04-09Revert "sideband: use writev(3p) to send pktlines"Junio C Hamano1-11/+3
This reverts commit 26986f4cbaf38d84a82b0b35da211389ce49552c; let's not use writev() for now.
2026-04-09Revert "cmake: use writev(3p) wrapper as needed"Junio C Hamano1-5/+1
This reverts commit 89152af176ea94ea8f3249115b6e00827fbbeb70; let's not use writev() for now.
2026-04-09A bit more for -rc2Junio C Hamano1-0/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-09Merge branch 'ds/rev-list-maximal-only-optim'Junio C Hamano4-0/+164
"git rev-list --maximal-only" has been optimized by borrowing the logic used by "git show-branch --independent", which computes the same kind of information much more efficiently. * ds/rev-list-maximal-only-optim: rev-list: use reduce_heads() for --maximal-only p6011: add perf test for rev-list --maximal-only t6600: test --maximal-only and --independent
2026-04-09Merge branch 'kh/doc-config-list'Junio C Hamano6-7/+6
"git config list" is the official way to spell "git config -l" and "git config --list". Use it to update the documentation. * kh/doc-config-list: doc: gitcvs-migration: rephrase “man page” doc: replace git config --list/-l with `list`
2026-04-09Merge branch 'jk/c23-const-preserving-fixes-more'Junio C Hamano15-45/+73
Further work to adjust the codebase for C23 that changes functions like strchr() that discarded constness when they return a pointer into a const string to preserve constness. * jk/c23-const-preserving-fixes-more: git-compat-util: fix CONST_OUTPARAM typo and indentation refs/files-backend: drop const to fix strchr() warning http: drop const to fix strstr() warning range-diff: drop const to fix strstr() warnings pkt-line: make packet_reader.line non-const skip_prefix(): check const match between in and out params pseudo-merge: fix disk reads from find_pseudo_merge() find_last_dir_sep(): convert inline function to macro run-command: explicitly cast away constness when assigning to void pager: explicitly cast away strchr() constness transport-helper: drop const to fix strchr() warnings http: add const to fix strchr() warnings convert: add const to fix strchr() warnings
2026-04-09Merge branch 'master' of https://github.com/git/gitJiang Xin153-1460/+3370
Upstream adds 8 new translatable messages. * 'master' of https://github.com/git/git: (93 commits) A bit more post -rc1 ... Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2026-04-08archive: document --prefix handling of absolute and parent pathsPushkar Singh1-0/+5
Clarify that --prefix is used as given and is not normalized, and may include leading slashes or parent directory components. Signed-off-by: Pushkar Singh <pushkarkumarsingh1970@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-08A bit more post -rc1Junio C Hamano1-0/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-08run_processes_parallel(): fix order of sigpipe handlingJeff King1-3/+8
In commit ec0becacc9 (run-command: add stdin callback for parallelization, 2026-01-28), we taught run_processes_parallel() to ignore SIGPIPE, since we wouldn't want a write() to a broken pipe of one of the children to take down the whole process. But there's a subtle ordering issue. After we ignore SIGPIPE, we call pp_init(), which installs its own cleanup handler for multiple signals using sigchain_push_common(), which includes SIGPIPE. So if we receive SIGPIPE while writing to a child, we'll trigger that handler first, pop it off the stack, and then re-raise (which is then ignored because of the SIG_IGN we pushed first). But what does that handler do? It tries to clean up all of the child processes, under the assumption that when we re-raise the signal we'll be exiting the process! So a hook that exits without reading all of its input will cause us to get SIGPIPE, which will put us in a signal handler that then tries to kill() that same child. This seems to be mostly harmless on Linux. The process has already exited by this point, and though kill() does not complain (since the process has not been reaped with a wait() call), it does not affect the exit status of the process. However, this seems not to be true on all platforms. This case is triggered by t5401.13, "pre-receive hook that forgets to read its input". This test fails on NonStop since that hook was converted to the run_processes_parallel() API. We can fix it by reordering the code a bit. We should run pp_init() first, and then push our SIG_IGN onto the stack afterwards, so that it is truly ignored while feeding the sub-processes. Note that we also reorder the popping at the end of the function, too. This is not technically necessary, as we are doing two pops either way, but now the pops will correctly match their pushes. This also fixes a related case that we can't test yet. If we did have more than one process to run, then one child causing SIGPIPE would cause us to kill() all of the children (which might still actually be running). But the hook API is the only user of the new feed_pipe feature, and it does not yet support parallel hook execution. So for now we'll always execute the processes sequentially. Once parallel hook execution exists, we'll be able to add a test which covers this. Reported-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-08Merge branch 'jt/index-fd-wo-repo-regression-fix'Junio C Hamano0-0/+0
During Git 2.52 timeframe, we broke streaming computation of object hash outside a repository, which has been corrected. * jt/index-fd-wo-repo-regression-fix:
2026-04-08Merge branch 'jt/index-fd-wo-repo-regression-fix-maint'Junio C Hamano2-11/+52
During Git 2.52 timeframe, we broke streaming computation of object hash outside a repository, which has been corrected. * jt/index-fd-wo-repo-regression-fix-maint: object-file: avoid ODB transaction when not writing objects
2026-04-08Merge branch 'tc/replay-ref'Junio C Hamano5-34/+157
The experimental `git replay` command learned the `--ref=<ref>` option to allow specifying which ref to update, overriding the default behavior. * tc/replay-ref: replay: allow to specify a ref with option --ref replay: use stuck form in documentation and help message builtin/replay: mark options as not negatable
2026-04-08Merge branch 'ng/add-files-to-cache-wo-rename'Junio C Hamano2-0/+39
add_files_to_cache() used diff_files() to detect only the paths that are different between the index and the working tree and add them, which does not need rename detection, which interfered with unnecessary conflicts. * ng/add-files-to-cache-wo-rename: read-cache: disable renames in add_files_to_cache
2026-04-08Merge branch 'ps/reftable-portability'Junio C Hamano18-70/+105
Update reftable library part with what is used in libgit2 to improve portability to different target codebases and platforms. * ps/reftable-portability: reftable/system: add abstraction to mmap files reftable/system: add abstraction to retrieve time in milliseconds reftable/fsck: use REFTABLE_UNUSED instead of UNUSED reftable/stack: provide fsync(3p) via system header reftable: introduce "reftable-system.h" header
2026-04-08Merge branch 'jd/cache-tree-trace-wo-the-repository'Junio C Hamano1-2/+2
Code cleanup. * jd/cache-tree-trace-wo-the-repository: cache-tree: use index state repository in trace2 calls
2026-04-08Merge branch 'ps/odb-cleanup'Junio C Hamano28-64/+72
Various code clean-up around odb subsystem. * ps/odb-cleanup: odb: drop unneeded headers and forward decls odb: rename `odb_has_object()` flags odb: use enum for `odb_write_object` flags odb: rename `odb_write_object()` flags treewide: use enum for `odb_for_each_object()` flags CodingGuidelines: document our style for flags
2026-04-08Merge branch 'ss/t7004-unhide-git-failures'Junio C Hamano1-5/+10
Test clean-up. * ss/t7004-unhide-git-failures: t7004: replace wc -l with modern test helpers
2026-04-08t1800: add &&-chains to test helper functionsAdrian Ratiu1-6/+6
Add the missing &&'s so we properly propagate failures between commands in the hook helper functions. Also add a missing mkdir -p arg (found by adding the &&). Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-04-08refs/reftable-backend: drop uses of the_repositoryShreyansh Paliwal1-3/+3
reftable_be_init() and reftable_be_create_on_disk() use the_repository even though a repository instance is already available, either directly or via struct ref_store. Replace these uses with the appropriate local repository instance (repo or ref_store->repo) to avoid relying on global state. Note that USE_THE_REPOSITORY_VARIABLE cannot be removed yet, as is_bare_repository() is still there in the file. Signed-off-by: Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail.com> Acked-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>