git/contrib/subtree/git-subtree.sh, 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

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

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

contrib/subtree: fix split with squashed subtrees

2025-09-11T16:01:15Z

98ba49ccc2 (subtree: fix split processing with multiple subtrees present, 2023-12-01) increases the performance of git subtree split --prefix=subA by ignoring subtree merges which are outside of `subA/`. It also introduces a regression. Subtree merges that should be retained are incorrectly ignored if they: 1. are nested under `subA/`; and 2. are merged with `--squash`. For example, a subtree merged like: git subtree merge --squash --prefix=subA/subB "$rev" # ^^^^^^^^ ^^^^ is erroneously ignored during a split of `subA`. This causes missing tree files and different commit hashes starting in git v2.44.0-rc0. The method: should_ignore_subtree_split_commit REV should test only a single commit REV, but the combination of git log -1 --grep=... actually searches all *parent* commits until a `--grep` match is discovered. Rewrite this method to test only one REV at a time. Extract commit information with a single `git` call as opposed to three. The `test` conditions for rejecting a commit remain unchanged. Unit tests now cover nested subtrees. Signed-off-by: Colin Stagner Acked-by: Phillip Wood Signed-off-by: Junio C Hamano

contrib/subtree: add -S/--gpg-sign

2025-06-04T16:32:17Z

Allows optionally signing the commits that git subtree creates. This can be necessary when working in a repository that requires gpg signed commits. Signed-off-by: Patrik Weiskircher Signed-off-by: Junio C Hamano

contrib/subtree: parse using --stuck-long

2025-06-04T16:32:17Z

Optional parameter handling only works unambiguous with git rev-parse --parseopt when using the --stuck-long option. To prepare for future commits which add flags with optional parameters, parse with --stuck-long. Signed-off-by: Patrik Weiskircher Signed-off-by: Junio C Hamano

contrib: fix typos

2024-10-10T20:31:12Z

Fix typos via codespell. Signed-off-by: Andrew Kreimer Signed-off-by: Junio C Hamano

subtree: fix split processing with multiple subtrees present

2024-01-25T18:56:34Z

When there are multiple subtrees present in a repository and they are all using 'git subtree split', the 'split' command can take a significant (and constantly growing) amount of time to run even when using the '--rejoin' flag. This is due to the fact that when processing commits to determine the last known split to start from when looking for changes, if there has been a split/merge done from another subtree there will be 2 split commits, one mainline and one subtree, for the second subtree that are part of the processing. The non-mainline subtree split commit will cause the processing to always need to search the entire history of the given subtree as part of its processing even though those commits are totally irrelevant to the current subtree split being run. To see this in practice you can use the open source GitHub repo 'apollo-ios-dev' and do the following in order: -Make a changes to a file in 'apollo-ios' and 'apollo-ios-codegen' directories -Create a commit containing these changes -Do a split on apollo-ios-codegen - Do a fetch on the subtree repo - git fetch git@github.com:apollographql/apollo-ios-codegen.git - git subtree split --prefix=apollo-ios-codegen --squash --rejoin - Depending on the current state of the 'apollo-ios-dev' repo you may see the issue at this point if the last split was on apollo-ios -Do a split on apollo-ios - Do a fetch on the subtree repo - git fetch git@github.com:apollographql/apollo-ios.git - git subtree split --prefix=apollo-ios --squash --rejoin -Make changes to a file in apollo-ios-codegen -Create a commit containing the change(s) -Do a split on apollo-ios-codegen - git subtree split --prefix=apollo-ios-codegen --squash --rejoin -To see that the patch fixes the issue you can use the custom subtree script in the repo so following the same steps as above, except instead of using 'git subtree ...' for the commands use 'git-subtree.sh ...' for the commands You will see that the final split is looking for the last split on apollo-ios-codegen to use as it's starting point to process commits. Since there is a split commit from apollo-ios in between the 2 splits run on apollo-ios-codegen, the processing ends up traversing the entire history of apollo-ios which increases the time it takes to do a split based on how long of a history apollo-ios has, while none of these commits are relevant to the split being done on apollo-ios-codegen. So this commit makes a change to the processing of commits for the split command in order to ignore non-mainline commits from other subtrees such as apollo-ios in the above breakdown by adding a new function 'should_ignore_subtree_commit' which is called during 'process_split_commit'. This allows the split/rejoin processing to still function as expected but removes all of the unnecessary processing that takes place currently which greatly inflates the processing time. In the above example, previously the final split would take ~10-12 minutes, while after this fix it takes seconds. Added a test to validate that the proposed fix solves the issue. The test accomplishes this by checking the output of the split command to ensure the output from the progress of 'process_split_commit' function that represents the 'extracount' of commits processed remains at 0, meaning none of the commits from the second subtree were processed. This was tested against the original functionality to show the test failed, and then with this fix to show the test passes. This illustrated that when using multiple subtrees, A and B, when doing a split on subtree B, the processing does not traverse the entire history of subtree A which is unnecessary and would cause the 'extracount' of processed commits to climb based on the number of commits in the history of subtree A. Signed-off-by: Zach FettersMoore Reviewed-by: Christian Couder Signed-off-by: Junio C Hamano