3 ms·
We're pretty worried about trying to monorepoize our existing code bases together. How do we not break all the merge commits that link a project specific PR? C
by jauntywundrkind 3y ago
We're pretty worried about trying to monorepoize our existing code bases together.
How do we not break all the merge commits that link a project specific PR? Complex filter-branch I guess. How do we make GitHub able to actually help us navigate the past effectively?
It seems like we need some custom tooling to help us replay the past step by step across multiple repos, doing some rewriting as we go.
And what if it's not just your own repos one is managing? What if you also are trying to manage external deps too?
I see much validity to wanting good git-of-gits. Also if anyone has any suggestions for stitching together monorepos out of existing repos, please please comment!
- sshine 3y ago> How do we not break all the merge commits that link a project specific PR? You won’t lose commits that are already made. Open PRs might become a problem, I’d reopen them in the monorepo; this could be automated. You would lose meaningful inter-linking for commits, PRs and issues, since they all have the same overlapping #xxx namespace. You could triage all issues to the new monorepo, but the tool for rewriting history to re-reference issues (in the monorepo) and PRs (with the to-be archived repo as prefix) does not, as far as I know, exist. But it’s doable with some scripting and the GitHub API. git filter-repo (not filter-branch) is wonderful for all the merging of repos, moving/splitting into subdirectories without git mv. > What if you also are trying to manage external deps too? I’d go with git sub-repo for that.