git/contrib/subtree, branch main

Merge branch 'cs/subtree-split-fixes'

2026-03-03T19:08:12Z

An earlier attempt to optimize "git subtree" discarded too much relevant histories, which has been corrected. * cs/subtree-split-fixes: contrib/subtree: process out-of-prefix subtrees contrib/subtree: test history depth contrib/subtree: capture additional test-cases

Merge branch 'ps/validate-prefix-in-subtree-split'

2026-03-03T01:06:51Z

"git subtree split --prefix=P " now checks the prefix P against the tree of the (potentially quite different from the current working tree) given commit. * ps/validate-prefix-in-subtree-split: subtree: validate --prefix against commit in split

contrib/subtree: process out-of-prefix subtrees

2026-02-20T18:15:31Z

`should_ignore_subtree_split_commit` detects subtrees which are outside of the current path --prefix and ignores them. This can speed up splits of repositories that have many subtrees. Since its inception [1], every iteration of this logic [2], [3] incorrectly excludes commits. This alters the split history. The split history and its commit hashes are API contract, so this is not permissible. While a commit from a different subtree may look like it doesn't contribute anything to a split, sometimes it does. Merge commits are a particular hot spot. For these, the pruning logic in `copy_or_skip` performs: 1. a check for "treesame" parents 2. two different common ancestry checks These checks operate on the **split history**, not the input history. The split history omits commits that do not affect the --prefix. This can significantly alter the ancestry of a merge. In order to determine if `copy_or_skip` will skip a merge, it is likely necessary to compute all the split history... which is what `should_ignore_subtree_split_commit` tries to avoid. To make this logic API-preserving, we could gate it behind a new CLI argument. The present implementation is actually a speed penalty in many cases, however, so this is not done here. Remove the `should_ignore_subtree_split_commit` logic. This fixes the regression reported in [4]. [1]: 98ba49ccc2 (subtree: fix split processing with multiple subtrees present, 2023-12-01) [2]: 83f9dad7d6 (contrib/subtree: fix split with squashed subtrees, 2025-09-09) [3]: 28a7e27cff (contrib/subtree: detect rewritten subtree commits, 2026-01-09) [4]: <20251230170719.845029-1-george@mail.dietrich.pub> Reported-by: George Reported-by: Christian Heusel Signed-off-by: Colin Stagner Signed-off-by: Junio C Hamano

contrib/subtree: test history depth

2026-02-20T18:15:31Z

Add history depth checks to some of the subtree unit tests. These checks were previously introduced as part of 28a7e27cff (contrib/subtree: detect rewritten subtree commits, 2026-01-09), which has since been reverted. Signed-off-by: Colin Stagner Signed-off-by: Junio C Hamano

contrib/subtree: capture additional test-cases

2026-02-20T18:15:31Z

Patch series e7b07376e5 (Merge branch 'rs/subtree-fixes', 2018-10-26) corrects several defects in `git subtree split`. The defects affect `split --rejoin` and merge commit processing. There is no test coverage for this, and e7b07376e5 did not introduce any. Convert the minimum working example [1] from the original patch submission [2] into test cases. [1]: https://gist.github.com/FoxFireX/1b794384612b7fd5e7cd157cff96269e [2]: <20180928183540.48968-1-roger.strain@swri.org> Signed-off-by: Colin Stagner Signed-off-by: Junio C Hamano

contrib/subtree: fix tests with reftable backend

2026-02-04T17:33:59Z

One git-subtree test-case relies on git internals to infer the default branch name. This test fails with the new reftable backend. GIT_TEST_DEFAULT_REF_FORMAT=reftable \ meson test t7900-subtree This test script already sets GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main which eliminates the need to infer a branch name at runtime. Hardcode the branch name. Signed-off-by: Colin Stagner Signed-off-by: Junio C Hamano

subtree: validate --prefix against commit in split

2026-02-03T17:26:45Z

git subtree split currently validates --prefix against the working tree. This breaks when splitting an older commit or when the working tree does not contain the subtree, even though the commit does. For example: git subtree split --prefix=pkg fails if pkg was removed later, even though it exists in . Fix this by validating the prefix against the specified commit using git cat-file instead of the working tree. Add a test to ensure this behavior does not regress. Signed-off-by: Pushkar Singh Signed-off-by: Junio C Hamano

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/

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

meson: make GIT_HTML_PATH configurable

2025-11-06T17:58:56Z

Makefile-based builds can configure Git's internal HTML_PATH by defining htmldir, which is useful for packagers that put documentation in different locations. Gentoo, for example, uses version-suffixed directories like ${prefix}/share/doc/git-2.51 and puts the HTML documentation in an 'html' subdirectory of the same. Propagate the same configuration knob to Meson-based builds so that "git --html-path" on such systems can be configured to output the correct directory. Signed-off-by: D. Ben Knoble Signed-off-by: Junio C Hamano