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