Re: [Bug] Git subtree regression

From: Colin Stagner <ask+git@howdoi.land>
Date: Jan 5, 2026, 03:36 UTC
Message-ID: <4a9c1a5f-336a-472c-af1d-7011fad776a6@howdoi.land>
In-Reply-To: <20260104142733.2334796-1-george@mail.dietrich.pub>

On 1/4/26 08:27, george@mail.dietrich.pub wrote:

> It does seem one component was added differently, as a non-merge commit, which seems break things.

Show 19 quoted lines

> ```
> # Create a LINEAR squash commit for subB (simulating cherry-pick of just the squash commit)
> # This is the key pattern that triggers the bug - a squash commit as a regular linear commit
> (
>      cd monorepo
>      mkdir -p subB
>      git -C ../subB archive HEAD | tar -x -C subB
>      git add subB
>      # Create a squash-style commit with subtree trailers but as a LINEAR commit
>      # Trailers must be in the last paragraph, separated by blank line
>      subB_short=$(git -C ../subB rev-parse --short HEAD)
>      subB_full=$(git -C ../subB rev-parse HEAD)
>      git commit -F - <<EOF
> Squashed 'subB/' content from commit $subB_short
> git-subtree-dir: subB
> git-subtree-split: $subB_full
> EOF
> )
> ```

Yes, this is very likely to cause breakage.

Normally,

     git subtree merge -P subA --squash

makes two commits, in this order:

1. Squashed 'subA/' content from commit f00...
2. Merge commit (1) as 'subA'

Commit 1 updates the subtree but does *not* rewrite paths. If you `git show` one, you will see that it has files like

     subA1
     subA2

and *not* subA/subA1.

The path rewrite actually takes place in Commit 2 (the merge), via the `-Xsubtree` merge strategy option.

`should_ignore_subtree_split_commit` tries to search for commits like (1), which all have the `git-subtree-*` trailer. Normally, these commits either have:

* no parents, if they result from a new `git subtree add --squash`; OR

* only parents which are also "Squashed 'subA/' content," if
   they result from a follow-up `git subtree merge --squash`

We can safely ignore these commits—and all of their parents—during a `subtree split` if they belong to a different subtree.

Of course, that heuristic doesn't work if the commit has been rebased onto other unrelated history—which is what happened in your repo.

I suspect the best way out may be to remove the `should_ignore_subtree_split_commit` heuristic entirely. It is mostly useful for repos that use `split --rejoin` a lot, and the check itself is slow. WDYT?

> How the first two commits show up as verified, unlike the other times when I normally do `git subtree add --squash` and push directly to main, they show up as unverified.

git v2.51.0 also adds --gpg-sign compatibility to subtree. Perhaps this is what you are seeing?

> It seems you also need to add `clock` as a remote and fetch it:

Ah, thanks.

Personally, I'm a big advocate for the monorepo layout. In my experience, it makes almost every task easier and faster.

Colin