We've got a fairly large codebase that's been through two previous source control systems, and recently converted to git. We have shared modules (but with customization) between projects, so subtrees looked like a good approach to sharing the code between projects. I've encountered a problem pushing commits back to the subtree repo which generated a question and maybe exposed an issue, though the issue could be with our repo for all I know. [first attempt 2.16.0 (windows), retried with same results 2.19.0 (windows)] Easier one first. Repo is set up to include code from another repo via subtree. We push code to the subtree using split --rejoin and get a commit linking the two together. New work is done on a branch that has a parent *before* the rejoin, and then merges back *after* the rejoin. When we later want to sync code using split --rejoin, am I right in believing that commit will appear parentless in the subtree repo, since the split will not process any commits which were reachable from the rejoin? If that's right, is there any workaround other than --ignore-rejoins? Doing the split already takes quite a while, and if we don't get the benefit of rejoins, that process will only grow longer. Harder part now. The actual problem I encountered was the remote claiming that my push couldn't be accepted because it was behind the remote HEAD of the branch. After looking closer at the local split, I discovered that the rejoin commit was not part of the new commit graph, which meant the commits were completely independent of the remote branch (hence the rejection). I reran the script with debug info turned on, and found the following result which was suspicious: Processing commit: c3630d64ec64c56b3395bb9df573031d770803af parents: 8a1d1a97bfd04a77b2cd624038f64a256753fa09 24b59e2a5f198d97a132a1c3080321a7238e176f newparents: 7da344d52155ec5cc3c67dde3577c6a99510ad05 224fa84a093a3b0fc801d0ee1a2f7732a94e3f98 tree is: 4b26d4dbe94c2ca43a4faa6c8e09f567400752d5 newrev is: 224fa84a093a3b0fc801d0ee1a2f7732a94e3f98 This commit is the merge which links the parentless new-work commits (merged as 224fa8) to the rejoin commit (accessible through 7da344). This particular commit should have been parented by both, but instead the script considered the two parents to be identical and simplified the graph to only use one. After digging into the script, it seems that this is because the tree hashes of the commits are the same. I've run a similar command to the one in the script to evaluate the hash information for both commits, including both tree hashes and commit hashes. There are some duplicate lines between the two, but they are clearly different commits with different histories. I've uploaded that output here, flagging the duplicate lines for convenience: https://gist.github.com/FoxFireX/41328a87bceeb3542c7a968348a92fa5 To further test this, I ran the script directly in (windows) bash, with the -x debug flag enabled on the script. It shows the comparison of the tree hashes, which is causing it to lose the parent that would link the branches together. That output is available here: https://gist.github.com/FoxFireX/d6b254d0f01af6533874eff2bb9ac135 I also went down the path of running the split with --ignore-joins (which I may need to do due to the first question anyway) but that process ended up creating an incorrect history that doesn't match the existing subtree, including a variety of commits which are completely unrelated to the subtree prefix. I haven't fully gone through the troubleshooting I want there, but may come back with other questions as I work through that process. So, am I right about branching from pre-rejoin causing ugly commits in the subtree later? And what can I do about this split that refuses to properly join back up? Any help or insight would be most appreciated. -- Roger Strain
