From: Colin Stagner <ask+git@howdoi.land>
Date: Sun, 04 Jan 2026 04:52:46 GMT
Subject: Re: [Bug] Git subtree regression
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.

> 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