I have a single mono repo that is being split to be 3 separate repos:
- Repo A: Feature one
- Repo B: Feature two
- Repo C: Dev repo that contains A and B as subtrees
The overall goal is to be able to develop in repo C, and consistently push changes for Repo A & B to their respective remote repos. An example flow would be something like this:
- Make changes to code in Repo C as well as subtrees A & B
- Commit work to Repo C
- Run the following commands on subtree A
git subtree split -P featureA --squash --rejoin -m "Commit message"- If changes were made to subtree A (based on split result) then
git subtree push -P featureA {remoteA} {targetBranchA}
- Then run the same commands on subtree B
git subtree split -P featureB --squash --rejoin -m "Commit message"- If changes were made to subtree B (based on split result) then
git subtree push -P featureB {remoteB} {targetBranchB}
- Then push the changes resulting from the subtree commands to the working branch on repo C
The issue I am seeing is that the --rejoin functionality of git subtree appears to not function correctly when using a workflow like this with multiple subtrees. If changes are only made to repo A for instance, each successive split command run successfully searches to the last --rejoin point found and stops (for example searches the last say 2 commits in the history).
However, when changes are made to both repos and each one runs the split command, the command now always searches the entire history failing to recognize any checkpoints from a previous --rejoin.
Wondering if anyone can provide any insight into what I may be doing wrong or how I could tweak this workflow to get it to work the way I would like?
I had played around extensively with variations of different subtree commands and trying to get it to rebuild its history with no luck.