git/contrib, branch v2.53.0

Revert "Merge branch 'cs/rebased-subtree-split'"

2026-01-26T06:37:35Z

This reverts commit 79e3055baba32e2952e6e8994cdcd4fc145ba7f0, reversing changes made to 9813aace1e52765e01e688672cdcdcbe25336ec7. Regresison report https://lore.kernel.org/git/755578cb-07e0-4b40-aa90-aacf4d45ccaa@heusel.eu/

Merge branch 'rs/tree-wo-the-repository'

2026-01-22T00:16:28Z

Remove implicit reliance on the_repository global in the APIs around tree objects and make it explicit which repository to work in. * rs/tree-wo-the-repository: cocci: remove obsolete the_repository rules cocci: convert parse_tree functions to repo_ variants tree: stop using the_repository tree: use repo_parse_tree() path-walk: use repo_parse_tree_gently() pack-bitmap-write: use repo_parse_tree() delta-islands: use repo_parse_tree() bloom: use repo_parse_tree() add-interactive: use repo_parse_tree_indirect() tree: add repo_parse_tree*() environment: move access to core.maxTreeDepth into repo settings

cocci: remove obsolete the_repository rules

2026-01-15T22:18:08Z

035c7de9e9e (cocci: apply the "revision.h" part of "the_repository.pending", 2023-03-28) removed the last of the repo-less functions and macros mentioned in the_repository.cocci at the time. No stragglers appeared since then. Remove the applied rules now that they have outlived their usefulness. Also add a reminder to eventually remove the just added rules for tree.h. Suggested-by: Patrick Steinhardt Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

contrib/subtree: detect rewritten subtree commits

2026-01-10T04:21:43Z

git subtree split --prefix P detects splits that are outside of path prefix `P` and prunes them from history graph processing. This improves the performance of repeated `split --rejoin` with many different prefixes. Both before and after 83f9dad7d6 (contrib/subtree: fix split with squashed subtrees, 2025-09-09), the pruning logic does not detect **rebased** or **cherry-picked** git-subtree commits. If `split` encounters any of these commits, the split output may have incomplete history. All commits authored by git subtree merge [--squash] --prefix Q have a first or second parent that has *only* subtree commits as ancestors. When splitting a completely different path `P/`, it is safe to ignore: 1. the merged tree 2. the subtree parent 3. *all* of that parent's ancestry, which applies only to path `Q/` and not `P/`. But this relationship no longer holds if the git-subtree commit is rebased or otherwise reauthored. After a rebase, the former git-subtree commit will have other unrelated commits as ancestors. Ignoring these commits may exclude the history of `P/`, leading to incomplete `subtree split` output. The pruning logic relies solely on the `git-subtree-*:` trailers to detect git-subtree commits, which it blindly accepts without further validation. The split logic also takes its time about being wrong: `cmd_split()` execs a `git show` for *every* commit in the split range… twice. This is inefficient in a shell script. Add a "reality check" to ignore rebased or rewritten commits: * Rewrites of non-merge commits cannot be detected, so the new detector no longer looks for them. * Merges carry a `git-subtree-mainline:` trailer with the hash of the **first parent**. If this hash differs, or if the "merge" commit no longer has multiple parents, a rewrite has occurred. To increase speed, package this logic in a new method, `find_other_splits()`. Perform the check up-front by iterating over a single `git log`. Add ignored subtrees to: 1. the `notree` cache, which excludes them from the `split` history 2. a `prune` negative refs list. The negative refs prevent recursing into other subtrees. Since there are potentially a *lot* of these, cache them on disk and use rev-list's `--stdin` mode. Reported-by: George Signed-off-by: Colin Stagner Signed-off-by: Junio C Hamano

cocci: convert parse_tree functions to repo_ variants

2026-01-10T02:36:18Z

Add and apply a semantic patch to convert calls to parse_tree() and friends to the corresponding variant that takes a repository argument, to allow the functions that implicitly use the_repository to be retired once all potential in-flight topics are settled and converted as well. The changes in .c files were generated by Coccinelle, but I fixed a whitespace bug it would have introduced to builtin/commit.c. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

Merge branch 'tc/memzero-array'

2025-12-23T02:33:16Z

MEMZERO_ARRAY() helper is introduced to avoid clearing only the first N bytes of an N-element array whose elements are larger than a byte. * tc/memzero-array: contrib/coccinelle: pass include paths to spatch(1) git-compat-util: introduce MEMZERO_ARRAY() macro

Merge branch 'jc/completion-no-single-letter-options'

2025-12-23T02:33:15Z

In-code comment update to clarify that single-letter options are outside of the scope of command line completion script. * jc/completion-no-single-letter-options: completion: clarify support for short options and arguments

Merge branch 'rs/ban-mktemp'

2025-12-16T02:08:35Z

Rewrite the only use of "mktemp()" that is subject to TOCTOU race and Stop using the insecure "mktemp()" function. * rs/ban-mktemp: compat: remove gitmkdtemp() banned.h: ban mktemp(3) compat: remove mingw_mktemp() compat: use git_mkdtemp() wrapper: add git_mkdtemp()

contrib/coccinelle: pass include paths to spatch(1)

2025-12-11T05:44:43Z

In the previous commit a new coccinelle rule is added. But neiter `make coccicheck` nor `meson compile coccicheck` did detect a case in builtin/last-modified.c. This case involves the field `scratch` in `struct last_modified`. This field is of type `struct bitmap` and that struct has a member `eword_t *words`. Both are defined in `ewah/ewok.h`. Now, while builtin/last-modified.c does include that header (with the subdir in the #include directive), it seems coccinelle does not process it. So it's unaware of the type of `words` in the bitmap, and it doesn't recognize the rule from previous commit that uses: type T; T *ptr; Fix coccicheck by passing all possible include paths inside the Git project so spatch(1) can find the headers and can determine the types. Signed-off-by: Toon Claes Signed-off-by: Junio C Hamano

git-compat-util: introduce MEMZERO_ARRAY() macro

2025-12-11T05:44:43Z

Introduce a new macro MEMZERO_ARRAY() that zeroes the memory allocated by ALLOC_ARRAY() and friends. And add coccinelle rule to enforce the use of this macro. Signed-off-by: Toon Claes Signed-off-by: Junio C Hamano