Instead of merging in the history of the entire subproject, just squash it
all into one commit, but try to at least track which commits we used so that
we can do future merges correctly.
Bonus feature: we can actually switch branches of the subproject this way,
just by "squash merging" back and forth from one tag to another.
If any one of the parents is the same as the current one, then clearly the
other parent branch isn't important, so throw it away entirely.
Can't remember why I didn't do this before, but if I rediscover it, it
definitely needs a unit test.
This is a simplification of the previous logic. I don't *think* it'll break
anything.
Results in far fewer useless merge commmits when playing with gitweb in the
git project:
git subtree split --prefix=gitweb --annotate='(split) ' 0a8f4f0^^..f2e7330
--onto=1130ef3
...and it doesn't *seem* to eliminate anything important.
Now we only prune out a commit if it has exactly one remaining parent and
that parent's tree is identical to ours.
But I also changed the test to create the initial "-s ours" merge in one
step instead of two, and that merge can be eliminated since one of its
parents doesn't affect the subdir at all, and is thus deleted.
Now we cut out a commit if any of its parents had the same tree; just use
that parent in its place. This makes the history look nice, but I don't
think it's quite right...
The idea is to join the new split branch back into this one, so future
splits can append themselves to the old split branch. We mark the split
branch's history in our merge commit, so we can pull it back out later.
