aboutsummaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)Author
2026-02-23config: format paths gentlyDerrick Stolee
Move the logic for formatting path config values into a helper method and use gentle parsing when needed. We need to be careful about how to handle the ':(optional)' macro, which as tested in t1311-config-optional.sh must allow for ignoring a missing path when other multiple values exist, but cause 'git config get' to fail if it is the only possible value and thus no result is output. In the case of our list, we need to omit those values silently. This necessitates the use of the 'gently' parameter here. Signed-off-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-23config: format bools or strings in helperDerrick Stolee
Move the logic for formatting bool-or-string config values into a helper. This parsing has always been gentle, so this is not unlocking new behavior. This extraction is only to match the formatting of the other cases that do need a behavior change. Signed-off-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-23config: format bools or ints gentlyDerrick Stolee
Move the logic for formatting bool-or-int config values into a helper method and use gentle parsing when needed. Signed-off-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-23config: format bools gentlyDerrick Stolee
Move the logic for formatting bool config values into a helper method and use gentle parsing when needed. This makes 'git config list --type=bool' not fail when coming across a non-boolean value. Such unparseable values are filtered out quietly. Signed-off-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-23config: format int64s gentlyDerrick Stolee
Move the logic for formatting int64 config values into a helper method and use gentle parsing when needed. Signed-off-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-23config: make 'git config list --type=<X>' workDerrick Stolee
Previously, the --type=<X> argument to 'git config list' was ignored and did nothing. Now, we add the use of format_config() to the show_all_config() function so each key-value pair is attempted to be parsed. This is our first use of the 'gently' parameter with a nonzero value. When listing multiple values, our initial settings for the output format is different. Add a new init helper to specify the fact that keys should be shown and also add the default delimiters as they were unset in some cases. Our intention is that if there is an error in parsing, then the row is not output. This is necessary to avoid the caller needing to build their own validator to understand the difference between valid, canonicalized types and other raw string values. The raw values will always be available to the user if they do not specify the --type=<X> option. The current behavior is more complicated, including error messages on bad parsing or potentially complete failure of the command. We add tests at this point that demonstrate the current behavior so we can witness the fix in future changes that parse these values quietly and gently. This is a change in behavior! We are starting to respect an option that was previously ignored, leading to potential user confusion. This is probably still a good option, since the --type argument did not change behavior at all previously, so users can get the behavior they expect by removing the --type argument or adding the --no-type argument. t1300-config.sh is updated with the current behavior of this formatting logic to justify the upcoming refactoring of format_config() that will incrementally fix some of these cases to be more user-friendly. Signed-off-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-23config: add 'gently' parameter to format_config()Derrick Stolee
This parameter is set to 0 for all current callers and is UNUSED. However, we will start using this option in future changes and in a critical change that requires gentle parsing (not using die()) to try parsing all values in a list. Signed-off-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-23config: move show_all_config()Derrick Stolee
In anticipation of using format_config() in this method, move show_all_config() lower in the file without changes. Signed-off-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-23refs: replace `refs_for_each_fullref_in()`Patrick Steinhardt
Replace calls to `refs_for_each_fullref_in()` with the newly introduced `refs_for_each_ref_ext()` function. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-23refs: replace `refs_for_each_glob_ref()`Patrick Steinhardt
Replace calls to `refs_for_each_glob_ref()` with the newly introduced `refs_for_each_ref_ext()` function. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-23refs: replace `refs_for_each_glob_ref_in()`Patrick Steinhardt
Replace calls to `refs_for_each_glob_ref_in()` with the newly introduced `refs_for_each_ref_ext()` function. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-23refs: replace `refs_for_each_rawref_in()`Patrick Steinhardt
Replace calls to `refs_for_each_rawref_in()` with the newly introduced `refs_for_each_ref_ext()` function. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-23refs: replace `refs_for_each_rawref()`Patrick Steinhardt
Replace calls to `refs_for_each_rawref()` with the newly introduced `refs_for_each_ref_ext()` function. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-23refs: replace `refs_for_each_ref_in()`Patrick Steinhardt
Replace calls to `refs_for_each_ref_in()` with the newly introduced `refs_for_each_ref_ext()` function. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-21pack-redundant: fix memory leak when open_pack_index() failsSahitya Chandra
In add_pack(), we allocate l.remaining_objects with llist_init() before calling open_pack_index(). If open_pack_index() fails we return NULL without freeing the allocated list, leaking the memory. Fix by calling llist_free(l.remaining_objects) on the error path before returning. Signed-off-by: Sahitya Chandra <sahityajb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-20Merge branch 'ps/for-each-ref-in-fixes' into ps/refs-for-eachJunio C Hamano
* ps/for-each-ref-in-fixes: bisect: simplify string_list memory handling bisect: fix misuse of `refs_for_each_ref_in()` pack-bitmap: fix bug with exact ref match in "pack.preferBitmapTips" pack-bitmap: deduplicate logic to iterate over preferred bitmap tips
2026-02-20Merge branch 'lo/repo-info-keys' into lo/repo-leftover-bitsJunio C Hamano
* lo/repo-info-keys: repo: add new flag --keys to git-repo-info repo: rename the output format "keyvalue" to "lines"
2026-02-20mailmap: stop using the_repositoryBurak Kaan Karaçay
The 'read_mailmap' and 'read_mailmap_blob' functions rely on the global 'the_repository' variable. Update both functions to accept a 'struct repository' parameter. Update all callers to pass 'the_repository' to retain the current behavior. Signed-off-by: Burak Kaan Karaçay <bkkaracay@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-19hook: add -z option to "git hook list"Adrian Ratiu
Add a NUL-terminate mode to git hook list, just in case hooks are configured with weird characters like newlines in their names. 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-02-19hook: include hooks from the configAdrian Ratiu
Teach the hook.[hc] library to parse configs to populate the list of hooks to run for a given event. Multiple commands can be specified for a given hook by providing "hook.<friendly-name>.command = <path-to-hook>" and "hook.<friendly-name>.event = <hook-event>" lines. Hooks will be started in config order of the "hook.<name>.event" lines and will be run sequentially (.jobs == 1) like before. Running the hooks in parallel will be enabled in a future patch. The "traditional" hook from the hookdir is run last, if present. A strmap cache is added to struct repository to avoid re-reading the configs on each rook run. This is useful for hooks like the ref-transaction which gets executed multiple times per process. Examples: $ git config --get-regexp "^hook\." hook.bar.command=~/bar.sh hook.bar.event=pre-commit # Will run ~/bar.sh, then .git/hooks/pre-commit $ git hook run pre-commit 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-02-19hook: add "git hook list" commandEmily Shaffer
The previous commit introduced an ability to run multiple commands for hook events and next commit will introduce the ability to define hooks from configs, in addition to the "traditional" hooks from the hookdir. Introduce a new command "git hook list" to make inspecting hooks easier both for users and for the tests we will add. Further commits will expand on this, e.g. by adding a -z output mode. 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-02-19hook: add internal state alloc/free callbacksAdrian Ratiu
Some hooks use opaque structs to keep internal state between callbacks. Because hooks ran sequentially (jobs == 1) with one command per hook, these internal states could be allocated on the stack for each hook run. Next commits add the ability to run multiple commands for each hook, so the states cannot be shared or stored on the stack anymore, especially since down the line we will also enable parallel execution (jobs > 1). Add alloc/free helpers for each hook, doing a "deep" alloc/init & free of their internal opaque struct. The alloc callback takes a context pointer, to initialize the struct at at the time of resource acquisition. These callbacks must always be provided together: no alloc without free and no free without alloc, otherwise a BUG() is triggered. Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-19path: remove repository argument from worktree_git_path()Phillip Wood
worktree_git_path() takes a struct repository and a struct worktree which also contains a struct repository. The repository argument was added by a973f60dc7c (path: stop relying on `the_repository` in `worktree_git_path()`, 2024-08-13) and exists because the worktree argument is optional. Having two ways of passing a repository is a potential foot-gun as if the the worktree argument is present the repository argument must match the worktree's repository member. Since the last commit there are no callers that pass a NULL worktree so lets remove the repository argument. This removes the potential confusion and lets us delete a number of uses of "the_repository". worktree_git_path() has the following callers: - builtin/worktree.c:validate_no_submodules() which is called from check_clean_worktree() and move_worktree(), both of which supply a non-NULL worktree. - builtin/fsck.c:cmd_fsck() which loops over all worktrees. - revision.c:add_index_objects_to_pending() which loops over all worktrees. - worktree.c:worktree_lock_reason() which dereferences wt before calling worktree_git_path(). - wt-status.c:wt_status_check_bisect() and wt_status_check_rebase() which are always called with a non-NULL worktree after the last commit. - wt-status.c:git_branch() which is only called by wt_status_check_bisect() and wt_status_check_rebase(). Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-19pack-bitmap: deduplicate logic to iterate over preferred bitmap tipsPatrick Steinhardt
We have two locations that iterate over the preferred bitmap tips as configured by the user via "pack.preferBitmapTips". Both of these callsites are subtly wrong: when the preferred bitmap tips contain an exact refname match, then we will hit a `BUG()`. Prepare for the fix by unifying the two callsites into a new `for_each_preferred_bitmap_tip()` function. This removes the last callsite of `bitmap_preferred_tips()` outside of "pack-bitmap.c". As such, convert the function to be local to that file only. Note that the function is still used by a second caller, so we cannot just inline it. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-19completion: fix zsh alias listing for subsection aliasesJonatan Holmgren
The zsh completion function __git_zsh_cmd_alias() uses 'git config --get-regexp' to enumerate aliases and then strips the "alias." prefix from each key. For subsection-style aliases (alias.name.command), this leaves "name.command" as the completion candidate instead of just "name". The bash completion does not have this problem because it goes through 'git --list-cmds=alias', which calls list_aliases() in C and already handles both alias syntaxes correctly. However, zsh needs both the alias name and its value for descriptive completion, which --list-cmds=alias does not provide. Add a hidden --aliases-for-completion option to 'git help', following the existing --config-for-completion pattern. It outputs NUL-separated "name\nvalue" pairs using list_aliases(), which correctly resolves both the traditional (alias.name) and subsection (alias.name.command) formats. Update __git_zsh_cmd_alias() to use it. Signed-off-by: Jonatan Holmgren <jonatan@jontes.page> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-17format-patch: fix From header in cover letterMirko Faina
"git format-patch" takes "--from=<user ident>" command line option and uses the given ident for patch e-mails, but this is not applied to the cover letter, the option is ignored and the committer ident of the current user is used. This has been the case ever since "--from" was introduced in a9080475 (teach format-patch to place other authors into in-body "From", 2013-07-03). Teach the make_cover_letter() function to honor the option, instead of always using the current committer identity. Change variable name from "committer" to "from" to better reflect the purpose of the variable. Signed-off-by: Mirko Faina <mroik@delayed.space> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-17Merge branch 'rs/clean-includes'Junio C Hamano
Clean up redundant includes of header files. * rs/clean-includes: remove duplicate includes
2026-02-17Merge branch 'rs/xdiff-wo-the-repository'Junio C Hamano
Reduce dependency on the_repository of xdiff-interface layer. * rs/xdiff-wo-the-repository: xdiff-interface: stop using the_repository
2026-02-17Merge branch 'yt/merge-file-outside-a-repository'Junio C Hamano
"git merge-file" can be run outside a repository, but it ignored all configuration, even the per-user ones. The command now uses available configuration files to find its customization. * yt/merge-file-outside-a-repository: merge-file: honor merge.conflictStyle outside of a repository
2026-02-17fetch-pack: wire up and enable auto filter logicChristian Couder
Previous commits have set up an infrastructure for `--filter=auto` to automatically prepare a partial clone filter based on what the server advertised and the client accepted. Using that infrastructure, let's now enable the `--filter=auto` option in `git clone` and `git fetch` by setting `allow_auto_filter` to 1. Note that these small changes mean that when `git clone --filter=auto` or `git fetch --filter=auto` are used, "auto" is automatically saved as the partial clone filter for the server on the client. Therefore subsequent calls to `git fetch` on the client will automatically use this "auto" mode even without `--filter=auto`. Let's also set `allow_auto_filter` to 1 in `transport.c`, as the transport layer must be able to accept the "auto" filter spec even if the invoking command hasn't fully parsed it yet. When an "auto" filter is requested, let's have the "fetch-pack.c" code in `do_fetch_pack_v2()` compute a filter and send it to the server. In `do_fetch_pack_v2()` the logic also needs to check for the "promisor-remote" capability and call `promisor_remote_reply()` to parse advertised remotes and populate the list of those accepted (and their filters). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-17fetch: make filter_options local to cmd_fetch()Christian Couder
The `struct list_objects_filter_options filter_options` variable used in "builtin/fetch.c" to store the parsed filters specified by `--filter=<filterspec>` is currently a static variable global to the file. As we are going to use it more in a following commit, it could become a bit less easy to understand how it's managed. To avoid that, let's make it clear that it's owned by cmd_fetch() by moving its definition into that function and making it non-static. This requires passing a pointer to it through the prepare_transport(), do_fetch(), backfill_tags(), fetch_one_setup_partial(), and fetch_one() functions, but it's quite straightforward. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-17clone: make filter_options local to cmd_clone()Christian Couder
The `struct list_objects_filter_options filter_options` variable used in "builtin/clone.c" to store the parsed filters specified by `--filter=<filterspec>` is currently a static variable global to the file. As we are going to use it more in a following commit, it could become a bit less easy to understand how it's managed. To avoid that, let's make it clear that it's owned by cmd_clone() by moving its definition into that function and making it non-static. The only additional change to make this work is to pass it as an argument to checkout(). So it's a small quite cheap cleanup anyway. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-17interactive -p: add new `--auto-advance` flagAbraham Samuel Adekunle
When using the interactive add, reset, stash or checkout machinery, we do not have the option of reworking with a file when selecting hunks, because the session automatically advances to the next file or ends if we have just one file. Introduce the flag `--auto-advance` which auto advances by default, when interactively selecting patches with the '--patch' option. However, the `--no-auto-advance` option does not auto advance, thereby allowing users the option to rework with files. Signed-off-by: Abraham Samuel Adekunle <abrahamadekunle50@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-17builtin/history: rename "--ref-action=" to "--update-refs="Patrick Steinhardt
With the preceding commit we have changed "--ref-action=" to only control which refs are supposed to be updated, not what happens with them. As a consequence, the option is now somewhat misnamed, as we don't control the action itself anymore. Rename it to "--update-refs=" to better align it with its new use. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-17builtin/history: replace "--ref-action=print" with "--dry-run"Patrick Steinhardt
The git-history(1) command has the ability to perform a dry-run that will not end up modifying any references. Instead, we'll only print any ref updates that would happen as a consequence of performing the operation. This mode is somewhat hidden though behind the "--ref-action=print" option. This command line option has its origin in git-replay(1), where it's probably an okayish interface as this command is sitting more on the plumbing side of tools. But git-history(1) is a user-facing tool, and this way of achieving a dry-run is way too technical and thus not very discoverable. Besides usability issues, it also has another issue: the dry-run mode will always operate as if the user wanted to rewrite all branches. But in fact, the user also has the option to only update the HEAD reference, and they might want to perform a dry-run of such an operation, too. We could of course introduce "--ref-action=print-head", but that would become even less ergonomic. Replace "--ref-action=print" with a new "--dry-run" toggle. This new toggle works with both "--ref-action={head,branches}" and is way more discoverable. Add a test to verify that both "--ref-action=" values behave as expected. This patch is best viewed with "--ignore-space-change". Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-17builtin/history: check for merges before asking for user inputPatrick Steinhardt
The replay infrastructure is not yet capable of replaying merge commits. Unfortunately, we only notice that we're about to replay merges after we have already asked the user for input, so any commit message that the user may have written will be discarded in that case. Fix this by checking whether the revwalk contains merge commits before we ask for user input. Adapt one of the tests that is expected to fail because of this check to use false(1) as editor. If the editor had been executed by Git, it would fail with the error message "Aborting commit as launching the editor failed." Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-17builtin/history: perform revwalk checks before asking for user inputPatrick Steinhardt
When setting up the revision walk in git-history(1) we also perform some verifications whether the request actually looks sane. Unfortunately, these verifications come _after_ we have already asked the user for the commit message of the commit that is to be rewritten. So in case any of the verifications fails, the user will have lost their modifications. Extract the function to set up the revision walk and call it before we ask for user input to fix this. Adapt one of the tests that is expected to fail because of this check to use false(1) as editor. If the editor had been executed by Git, it would fail with the error message "Aborting commit as launching the editor failed." Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-14repo: add new flag --keys to git-repo-infoLucas Seiki Oshiro
If the user wants to find what are the available keys, they need to either check the documentation or to ask for all the key-value pairs by using --all. Add a new flag --keys for listing only the available keys without listing the values. Signed-off-by: Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-14repo: rename the output format "keyvalue" to "lines"Lucas Seiki Oshiro
Both subcommands in git-repo(1) accept the "keyvalue" format. This format is newline-delimited, where the key is separated from the value with an equals sign. The name of this option is suboptimal though, as it is both too limiting while at the same time not really indicating what it actually does: - There is no mention of the format being newline-delimited, which is the key differentiator to the "nul" format. - Both "nul" and "keyvalue" have a key and a value, so the latter is not exactly giving any hint what makes it so special. - "keyvalue" requires there to be, well, a key and a value, but we want to add additional output that is only going to be newline delimited. Taken together, "keyvalue" is kind of a bad name for this output format. Luckily, the git-repo(1) command is still rather new and marked as experimental, so things aren't cast into stone yet. Rename the format to "lines" instead to better indicate that the major difference is that we'll get newline-delimited output. This new name will also be a better fit for a subsequent extension in git-repo(1). Helped-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Lucas Seiki Oshiro <lucasseikioshiro@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-13Merge branch 'sb/merge-ours-sparse'Junio C Hamano
"git merge-ours" is taught to work better in a sparse checkout. * sb/merge-ours-sparse: merge-ours: integrate with sparse-index merge-ours: drop USE_THE_REPOSITORY_VARIABLE
2026-02-13Merge branch 'ps/commit-list-functions-renamed'Junio C Hamano
Rename three functions around the commit_list data structure. * ps/commit-list-functions-renamed: commit: rename `free_commit_list()` to conform to coding guidelines commit: rename `reverse_commit_list()` to conform to coding guidelines commit: rename `copy_commit_list()` to conform to coding guidelines
2026-02-13Merge branch 'tc/last-modified-not-a-tree'Junio C Hamano
Giving "git last-modified" a tree (not a commit-ish) died an uncontrolled death, which has been corrected. * tc/last-modified-not-a-tree: last-modified: verify revision argument is a commit-ish last-modified: remove double error message last-modified: fix memory leak when more than one commit is given last-modified: rewrite error message when more than one commit given
2026-02-13Merge branch 'cf/c23-const-preserving-strchr-updates-0'Junio C Hamano
ISO C23 redefines strchr and friends that tradiotionally took a const pointer and returned a non-const pointer derived from it to preserve constness (i.e., if you ask for a substring in a const string, you get a const pointer to the substring). Update code paths that used non-const pointer to receive their results that did not have to be non-const to adjust. * cf/c23-const-preserving-strchr-updates-0: gpg-interface: remove an unnecessary NULL initialization global: constify some pointers that are not written to
2026-02-12sparse-checkout: use string_list_sort_uAmisha Chhajed
sparse_checkout_list() uses string_list_sort and string_list_remove_duplicates instead of string_list_sort_u. use string_list_sort_u at that place. Signed-off-by: Amisha Chhajed <136238836+amishhaa@users.noreply.github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-12builtin/fsck: fix flags passed to `odb_has_object()`Patrick Steinhardt
In `mark_object()` we invoke `has_object()` with a value of 1. This is somewhat fishy given that the function expects a bitset of flags, so any behaviour that this results in is purely coincidental and may break at any point in time. The call to `has_object()` was originally introduced in 9eb86f41de (fsck: do not lazy fetch known non-promisor object, 2020-08-05). The intent here was to skip lazy fetches of promisor objects: we have already verified that the object is not a promisor object, so if the object is missing it indicates a corrupt repository. The hardcoded value that we pass maps to `HAS_OBJECT_RECHECK_PACKED`, which is probably the intended behaviour: `odb_has_object()` will not fetch promisor objects unless `HAS_OBJECT_FETCH_PROMISOR` is passed, but we may want to verify that no concurrent process has written the object that we're trying to read. Convert the code to use the named flag instead of the the hardcoded value. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-12builtin/backfill: fix flags passed to `odb_has_object()`Patrick Steinhardt
The function `fill_missing_blobs()` receives an array of object IDs and verifies for each of them whether the corresponding object exists. If it doesn't exist, we add it to a set of objects and then batch-fetch all of the objects at once. The check for whether or not we already have the object is broken though: we pass `OBJECT_INFO_FOR_PREFETCH`, but `odb_has_object()` expects us to pass `HAS_OBJECT_*` flags. The flag expands to: - `OBJECT_INFO_QUICK`, which asks the object database to not reprepare in case the object wasn't found. This makes sense, as we'd otherwise reprepare the object database as many times as we have missing objects. - `OBJECT_INFO_SKIP_FETCH_OBJECT`, which asks the object database to not fetch the object in case it's missing. Again, this makes sense, as we want to batch-fetch the objects. This shows that we indeed want the equivalent of this flag, but of course represented as `HAS_OBJECT_*` flags. Luckily, the code is already working correctly. The `OBJECT_INFO` flag expands to `(1 << 3) | (1 << 4)`, none of which are valid `HAS_OBJECT` flags. And if no flags are passed, `odb_has_object()` ends up calling `odb_read_object_info_extended()` with exactly the above two flags that we wanted to set in the first place. Of course, this is pure luck, and this can break any moment. So let's fix this and correct the code to not pass any flags at all. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-11Merge branch 'rs/blame-ignore-colors-fix'Junio C Hamano
"git blame --ignore-revs=... --color-lines" did not account for ignored revisions passing blame to the same commit an adjacent line gets blamed for. * rs/blame-ignore-colors-fix: blame: fix coloring for repeated suspects
2026-02-11Merge branch 'sp/show-index-warn-fallback'Junio C Hamano
When "git show-index" is run outside a repository, it silently defaults to SHA-1; the tool now warns when this happens. * sp/show-index-warn-fallback: show-index: use gettext wrapping in user facing error messages show-index: warn when falling back to SHA-1 outside a repository
2026-02-11builtin/pack-objects: don't fetch objects when merging packsPatrick Steinhardt
The "--stdin-packs" option can be used to merge objects from multiple packfiles given via stdin into a new packfile. One big upside of this option is that we don't have to perform a complete rev walk to enumerate objects. Instead, we can simply enumerate all objects that are part of the specified packfiles, which can be significantly faster in very large repositories. There is one downside though: when we don't perform a rev walk we also don't have a good way to learn about the respective object's names. As a consequence, we cannot use the name hashes as a heuristic to get better delta selection. We try to offset this downside though by performing a localized rev walk: we queue all objects that we're about to repack as interesting, and all objects from excluded packfiles as uninteresting. We then perform a best-effort rev walk that allows us to fill in object names. There is one gotcha here though: when "--exclude-promisor-objects" has not been given we will perform backfill fetches for any promised objects that are missing. This used to not be an issue though as this option was mutually exclusive with "--stdin-packs". But that has changed recently, and starting with dcc9c7ef47 (builtin/repack: handle promisor packs with geometric repacking, 2026-01-05) we will now repack promisor packs during geometric compaction. The consequence is that a geometric repack may now perform a bunch of backfill fetches. We of course cannot pass "--exclude-promisor-objects" to fix this issue -- after all, the whole intent is to repack objects part of a promisor pack. But arguably we don't have to: the rev walk is intended as best effort, and we already configure it to ignore missing links to other objects. So we can adapt the walk to unconditionally disable fetching any missing objects. Do so and add a test that verifies we don't backfill any objects. Reported-by: Lukas Wanko <lwanko@gitlab.com> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-10xdiff-interface: stop using the_repositoryRené Scharfe
Use the algorithm-agnostic is_null_oid() and push the dependency of read_mmblob() on the_repository->objects to its callers. This allows it to be used with arbitrary object databases. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>