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@xxxxxxxxx/
[3]:
http://archive.ubuntu.com/ubuntu/pool/main/g/git/git_2.43.0-1ubuntu7.3_amd64.deb