Remix.run Logo
mikestorrent 4 hours ago

I think it's making sense. Many of my workflows involve e.g. multiple different repos that house different parts of something (e.g. deployment automation is over here, application itself is over there, sometimes a change needs to happen to both at once). I find myself having to work serially on tickets because two different issues might touch the same repos and so I manually maintain branches and switch around between them; this adds starting friction to my work.

mst98 4 hours ago | parent [-]

Ah, if in different repos that would map to different hives, so that would require switching between hives in the top left drop down. Still persistent, but not as streamlined as clones within the same repo / combs in same hive. I have been spoiled (?) by monorepos so that's why designed for this.

verdverm 4 hours ago | parent [-]

> I have been spoiled (?) by monorepos so that's why designed for this.

I too find monorepos superior at this point in time. There are essentially the same complexities both ways (polyrepo), two sides of the same coin. I have broken slightly, having "megarepos", where most code is in one place, but a few are broken out, possibly another "megarepo". The most natural split is public vs private.