You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should be able to use Josh to stitch a "virtual monorepo" from a range of remote repo sources for advanced code synchronization without using hacky solution such as git subtree or git submodule.
In other word, we form one single big history from multiple smaller sources, which still fits the "Just One Single History" philosophy.
just my two cents, as someone who is tasked with migrated a poly-repo setup at work to a mono-repo, this would make such a migration trivial, since you could just combine the histories and continue development in the poly-repos (ensuring development isn't blocked) until the mono-repo is stable and ready to be released.
then to migrate you would just need to set a cutoff date for merging PRs into the old poly-repos, past that date you are expected to target new PRs or rebase old ones to the new mono-repo. Given enough time you should be able to get most sigificant works merged in the old poly-repos before that date, ensuring a smooth transition with minimal blockage.
Just wanted to emphasize a usecase for such a feature, as I am about to experience some pain from not having it 😂
We should be able to use Josh to stitch a "virtual monorepo" from a range of remote repo sources for advanced code synchronization without using hacky solution such as
git subtree
orgit submodule
.In other word, we form one single big history from multiple smaller sources, which still fits the "Just One Single History" philosophy.
Related discussion: #1299
Also related: dotnet/announcements#241
The text was updated successfully, but these errors were encountered: