Thanks for the response. I began to wonder if indeed I was using the correct paradigm, since the split operation would leave the subtree prefix as `/` which is an impossible prefix when creating a subtree. Attempting to add a new subtree with prefix `/` results in an error because the prefix directory is not empty (it contains `.git`). Long story short, I realized I probably had to start over without using subtree at all and manually rebase and remerge. I discovered that now that I'm not using subtree, I can no longer squash merge. It works for the first merge but subsequent squashes do not remember what the previous squash's parent commit was from the other repo. (The subtree subsequent squash merge experience was perfect.) I decided to be okay with that and give up the idea of squashes; I can use `git log --author=jnm2` so that I can actually read my history, and in the unlikely scenario that I can't access the other repo at least I'll have full history. The only thing I dislike is that I'm giving up the concept of that separation between two repos in the same working tree- that some files belong to one repo and some to the other. That's a cool paradigm. Since my access to the other repo is read only, I suppose that doesn't matter. I can't use subtree because the prefix would be `/`, and I can't use submodule because my repo needs to track my changes inside the prefix as part of my repo. > I have not tested this, but I wonder what would happen if you either deleted that history from the host repository or you cloned the host repository to a new place and tried the split there. I tried that in the course of my tests earlier; if I remember correctly, I lost the squash merge history. Git log showed only the parents from my repo. I couldn't do a new squash merge because it lost track of the most recent squash's parent commit in the other repo. > I never imagined that someone would *not* want to get the original history back It's possible that what I was trying to do made no sense in the first place. It's likely that I'm missing something since I'm new to these concepts. I feel like I've settled for a less clean solution but I can't put my finger on it. I'm willing to try a different configuration. Joseph -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html