subtree: [v2.44 regression] split may produce different history

98ba49ccc247 likely introduces a regression in "git subtree split" [1] [2]. For some inputs, the split history is incomplete and does not match previous git versions.

For

     git subtree split -P somedir

if the history of `somedir` also contains *squashed* subtree *merges*, the split history may be incomplete. MWE follows:

```bash git init mwe && cd mwe

# create history we will subtree merge later git checkout --orphan deeper touch two_deep && git add two_deep git commit -m 'deeper: a nested subtree'

# create top-level project history with one # subproject in a directory sub/ git checkout --orphan main git reset --hard echo 'A test for git-subtree'>README.txt mkdir sub && touch sub/README.sub.txt git add . git commit -m 'Initial commit'

# add "deeper" branch as sub/deeper # the --squash is important here since it omits # "git-subtree-mainline:", which 98ba49ccc247 # looks for in `should_ignore_subtree_split_commit()` git subtree add --squash -P sub/deeper deeper ```

Now `git ls-tree --name-only -r main` looks like this:

     README.txt
     sub/README.sub.txt
     sub/deeper/two_deep

We can split `sub` off as its own top-level history.

```bash
git ls-tree -r --name-only -- \
   "$(git subtree.sh split -P sub)"
```

Before the patch, that looks like:

     README.sub.txt
     deeper/two_deep

Which is correct. After the patch, there is only:

     README.sub.txt

which is missing the entire `deeper/` directory. (The hash output from `split` is also different.)

I suspect the test in `should_ignore_subtree_split_commit ()` inadvertently rejects commits that should be kept.

I tested with Git binaries from v2.43 on Ubuntu [3].

[1]: https://git.kernel.org/pub/scm/git/git.git/commit/?id=98ba49ccc247c3521659aa3d43c970e8978922c5

[2]: https://lore.kernel.org/all/pull.1587.v6.git.1701442494319.gitgitgadget@gmail.com/

[3]: http://archive.ubuntu.com/ubuntu/pool/main/g/git/git_2.43.0-1ubuntu7.3_amd64.deb