Re: [Bug] Git subtree regression

From: Colin Stagner <ask+git@howdoi.land>
Date: Jan 4, 2026, 04:52 UTC
Message-ID: <e25b4d76-c1b5-4b6b-ba77-e1e2f7243ce9@howdoi.land>
In-Reply-To: <20251230170719.845029-1-george@mail.dietrich.pub>

Hello, George!

Thanks for looking in to this.

On 12/30/25 11:07, george@mail.dietrich.pub wrote:

> ---
> I explored this more and think I found the root cause.
> Commit `83f9dad7d6fb5988b68f80b25bd87c68693195dd` changed `should_ignore_subtree_split_commit()` to examine only a commit's own trailers via `git show --format='%(trailers:...)'`.
> The old code used `git log -1 --grep=...` which had the important side effect of searching through ancestor commits.

The old `--grep=...` approach was introduced as a performance speedup for large splits. I don't believe the original author intended to alter the split result, but the old approach inadvertently did in some cases.

> # 2.52.0 produces broken result
> $ git subtree split --prefix="src/components/clock"
> 0efb3d9858e3bfee65165508aeeacc50417c9a99  # 7 commits,

On v2.52.0 on my machine, I get an error instead:

      fatal: could not rev-parse split hash 
d0ed70566b3e962fbff71145d8155986b48c6885 from commit 
5817d4435bf448f526c3b0049f00e6500277e4bb

I presume I need more history than just master to make this work.

Can you test this split command in git v2.43.7? This is before `should_ignore_subtree_split_commit()` was introduced.

I'd like to distill this down into a minimum working example that doesn't depend on an external repo like athena. Namely, some shell instructions that start from an empty `git init` and create a repo with the bug condition. That way, we know exactly and narrowly what sort of history graph produces the bug. I think I have almost enough information here to do that, but you're welcome to try writing an MWE yourself.

Show 7 quoted lines

> In a multi-subtree monorepo with this topology:
> 
> ```
>    main:    A---B---M---E    (B = subtree add --squash for subA)
>                    /
>    feature:   C---D          (D = subtree add --squash for subB)
> ```

Just to verify: in this example, is commit M a normal merge commit? Or is it also created with subtree?

Colin