Re: [PATCH 3/3] contrib/subtree: process out-of-prefix subtrees

>
> `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 <george@mail.dietrich.pub>
>
> Reported-by: Christian Heusel <christian@heusel.eu>
>
> Signed-off-by: Colin Stagner <ask+git@howdoi.land>