Subtree bugs

["Strain, Roger L." <roger.strain@swri.org>]

I emailed the group yesterday regarding a possible error in the subtree script. I've continued debugging and since have been able to reproduce the problem. In fact, there are two failure cases which may expose three different problems. To demonstrate, the following commands create two repos (main and sub), add a variety of commits, perform some merges, splits, and rejoins, and finally perform two splits. These two splits generate a commit history which cannot be pushed back to the subtree repo in two different manners.

Commands to demonstrate both failures are here:
https://gist.github.com/FoxFireX/1b794384612b7fd5e7cd157cff96269e

Short summary of three problems involved:
1. Split using rejoins fails in some cases where a commit has a parent which was a parent commit further upstream from a rejoin, causing a new initial commit to be created, which is not related to the original subtree commits.
2. Split using rejoins fails to generate a merge commit which may have triaged the previous problem, but instead elected to use only the parent which is not connected to the original subtree commits. (This may occur when the commit and both parents all share the same subtree hash.)
3. Split ignoring joins also ignores the original add commit, which causes content prior to the add to be considered part of the subtree graph, changing the commit hashes so it is not connected to the original subtree commits.

I'm going to start looking at how to fix/work around either or both of these issues because it's holding up some work for us, but if anyone else has seen something like this, or has suggestions, I'd be happy to hear them.  If I do come up with a fix, I'll ask for approval to contribute it back.

-- 
Roger Strain