Monorepoize – Bash scripts for creating a monorepo out of smaller repos
1–10 of 103 posts
Re: Monorepoize – Bash scripts for creating a monorepo out of smaller repos
#2What is the advantage over using `git subtree`?
Re: Monorepoize – Bash scripts for creating a monorepo out of smaller repos
#3Why is there so much code? Both python and bash. What are the edge cases that it is handling? What niceties does it introduce that you might otherwise miss out on?
I combined ~10 repos last year use a few one liners and loops.
Re: Monorepoize – Bash scripts for creating a monorepo out of smaller repos
#4I feel bad about plugging myself into a post to Peter Seibel's work, but if you're interested in this kind of git preservation, I wrote a script to move a subfolder between two repos:
https://github.com/jakub-g/git-move-folder-between-repos-kee...
(I didn't use it for a while, but it worked for my case a few times in the past).
Re: Monorepoize – Bash scripts for creating a monorepo out of smaller repos
#5In the last few years, I saw a lot of people using monorepos, and discouraging using submodules.
Frankly, I don't know why. For small projects, sure - it it an overhead. For anything larger, I find it useful to encapsulate things - be it installable packages, or if it is not the case - at least other repositories.
In the last months I split one project into 4 repos (https://github.com/Quantum-Game/) and couldn't be happier about that move. It makes the code cleaner, Pull Requests more separated, etc.
Re: Monorepoize – Bash scripts for creating a monorepo out of smaller repos
#6In the last few years, I saw a lot of people using monorepos, and discouraging using submodules. Frankly, I don't know why. For small projects, sure - it it an overhead. For anything larger, I find it useful to encapsulate things - be it installable packages, or if it is not the case - at least other repositories. In the last months I split one project into 4 repos ( https://github.com/Quantum-Game/ ) and couldn't be…
Once your code grows and you end up with too many repos you'll be yearning to get back to monorepos. It allows to make changes in one go instead of having 3-4 PRs that all have to be merged at same time or otherwise the build breaks.
Having separate repos only makes sense if they are maintained by separate teams with a well defined API in-between that doesn't change often. If the same team maintains all repos then it is just overhead, especially if you end up with a 100 repos and you have significantly less than 100 engineers in your team.
There are also potential build time savings when having a monorepo since you can do parallel builds across different subdirs without serialising at package boundaries.
Re: Monorepoize – Bash scripts for creating a monorepo out of smaller repos
#7Big corporations are extremely inefficient. Why does everyone want to copy them?
And why do we use all the bulky tools they produce when there are far simpler, better and more open alternatives available?
Re: Monorepoize – Bash scripts for creating a monorepo out of smaller repos
#8In the last few years, I saw a lot of people using monorepos, and discouraging using submodules. Frankly, I don't know why. For small projects, sure - it it an overhead. For anything larger, I find it useful to encapsulate things - be it installable packages, or if it is not the case - at least other repositories. In the last months I split one project into 4 repos ( https://github.com/Quantum-Game/ ) and couldn't be…
Once your code grows and you end up with too many repos you'll be yearning to get back to monorepos. It allows to make changes in one go instead of having 3-4 PRs that all have to be merged at same time or otherwise the build breaks. Having separate repos only makes sense if they are maintained by separate teams with a well defined API in-between that doesn't change often. If the same team maintains all repos then it…
I maintain such a project with many dependencies which I also maintain separately. Yes it can be a lot of extra work to publish but this argument is based on the assumption that dependencies need to be changed constantly and this assumption is wrong. There should be pressure to design dependencies in such a way that they are modular and don't need to be changed often - This unpleasantness associated with updating deep dependencies is good and necessary. These should rarely be updated, if they need to be updated often, then they were designed incorrectly.
Many of the dependencies and sub-dependencies which I maintain are several years old. They are small enough and stable enough that they basically never need to change.
If I need to update them (which is rare), I may need to do a cascading update of multiple dependents and this can take a while but if I have to do this big update only once every 6 months, it's totally worth having them in separate repos.
Re: Monorepoize – Bash scripts for creating a monorepo out of smaller repos
#9Big corporations are extremely inefficient. Why does everyone want to copy them? And why do we use all the bulky tools they produce when there are far simpler, better and more open alternatives available?
Because it turns out big corporations that use multirepos tend to be even less efficient (about versioning) than those that use monorepos.
What are those far simpler, better, more open alternatives?
Re: Monorepoize – Bash scripts for creating a monorepo out of smaller repos
#10In the last few years, I saw a lot of people using monorepos, and discouraging using submodules. Frankly, I don't know why. For small projects, sure - it it an overhead. For anything larger, I find it useful to encapsulate things - be it installable packages, or if it is not the case - at least other repositories. In the last months I split one project into 4 repos ( https://github.com/Quantum-Game/ ) and couldn't be…
Once your code grows and you end up with too many repos you'll be yearning to get back to monorepos. It allows to make changes in one go instead of having 3-4 PRs that all have to be merged at same time or otherwise the build breaks. Having separate repos only makes sense if they are maintained by separate teams with a well defined API in-between that doesn't change often. If the same team maintains all repos then it…
> Having separate repos only makes sense if they are maintained by separate teams with a well defined API
Agree! I've found that a multirepo setup only works if there's an obvious boundary. Similar to SOA, distributed monoliths - or distributed monorepos - are problematic.