git-subtree split misbehaviour with a commit having empty ls-tree for the specified subdir

[Ed Maste <emaste@freebsd.org>]

I encountered an issue while trying to use git subtree with the
FreeBSD svn->git mirror: I found that when "git subtree split"
encounters a commit with an empty "git ls-tree" for the subdirectory
being split, it ends up recording the original parent as the new
parent in the split history that's being created. This then leads to
unrelated history appearing in the split subtree.

Below is a shell script that demonstrates the issue - this is not the
precise case that I encountered in the FreeBSD repo, but the behaviour
is identical (and it doesn't take nearly 10 minutes to run). Running
the script and then "git log" of the commit printed by the final (git
subtree) command includes the unrelated history in dir2/.

It looks like this comes from the cache_set "$rev" "$rev" in
process_split_commit() added in 39f5fff0d53. This is under the
suspicious-looking "ugly. is there no better way to tell if this is a
subtree vs. a mainline commit? Does it matter" comment. However, I
don't yet understand enough of git-subtree's operation to propose a
fix.

--repro.sh--
#!/bin/sh

rm -rf subrepo-issue
mkdir -p subrepo-issue
cd subrepo-issue

git init .
mkdir -p dir1 dir2
touch dir1/file1 dir2/file2
git add dir1 dir2
git commit -m 'initial commit'
echo 'file2' > dir2/file2
git commit -m 'file2 modified' dir2/file2
git rm dir1/file1
git commit -m 'remove file1'
mkdir -p dir1
touch dir1/file1
git add dir1
git commit -m 'restore file1'
echo 'file1' > dir1/file1
git commit -m 'file1 modified' dir1/file1
git subtree split --prefix=dir1/