Re: [Bug] Git subtree regression

[Colin Stagner <ask+git@howdoi.land>]

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.

> ```
> # 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