3 ms·

> Monorepos are indeed causing problems with git, and this is one of the main arguments against them (see [1]). The article is a disappointing read. It spends

by foofie 3y ago

> Monorepos are indeed causing problems with git, and this is one of the main arguments against them (see [1]). The article is a disappointing read. It spends a lot of time talking about monorepos and how they spell all sorts of trouble. Yet, the article makes zero mentions of submodules as a way to get the best of both worlds.

kristjansson 3y ago
Submodules are great, but they're hardly an alternative to monorepos.
- carlthome 3y ago
  Why not? Just want to understand.
  - jitl 3y ago
    Submodule workflows have a lot of overhead at review time. During development it's fine, you work with the fully materialized tree just like it's a monorepo. But once you need to submit your changes for review, how does that workflow look? 1. Commit in submodule A, then get it reviewed and merged as SHA 123 2. Update submodule A to 123, get it reviewed 3. Reviewer has feedback on usage of new API in submodule A 4. Make another PR on A, at commit 457. This time don't merge it since reviewer on main repo might have more feedback. Monorepo: 1. Make PR to monorepo 2. Get review feedback 3. Push changes to PR branch 4. Merge 5. Update submodule to 456, push to existing PR ...??
    - foofie 3y ago
      > But once you need to submit your changes for review, how does that workflow look? 1. Post PR to submoduke A. Get it merged. 2. Post PR to the main repo updating it to point to subproject A. Done. The only difference between a monorepo and splitting the repo into submodules is that the main repo's history is coarser and basically tracks the output of integration tests. There is no need to overcomplicate things, and if you need to overthink them anyway then you have far more degrees of freedom to worry about in monorepos.
      - vlovich123 3y ago
        That’s a really slow review process. It also prevents reviewers from seeing the bigger picture of how step 1 manifests in step 2. In practice what I’ve seen you end up with both reviews simultaneously referencing each other in the description and once approved you merge 1 and update the pointer in 2 to point to the new merged commit if it changed. That’s a lot of annoying and sometimes error prone manual bookkeeping that has nothing to do with the engineering work itself
  - kristjansson 3y ago
    Anything that cuts across submodule boundaries needs as many MRs as boundaries it crosses, conflicting submodule pointer updates in the main require additional MRs (in the submodules) to resolve and coordination between those MRs. They're basically fine for slowly-moving dependencies, vendoring, etc. but they emphatically do not solve the large-org many-team coordination problems that monorepos are meant to solve. FWIW, git is a great monorepo platform for 1-10m lines of code (Linux, $MY_JOB, ...). It's only the very largest scales (Windows, Google3, ...) or asset heavy cases (ML, game dev) that need special treatment.
- sitzkrieg 3y ago
  ive never seen positive feedback for submodules before

by foofie 3y ago

kristjansson 3y ago

Submodules are great, but they're hardly an alternative to monorepos.

carlthome 3y ago
Why not? Just want to understand.
- jitl 3y ago
  Submodule workflows have a lot of overhead at review time. During development it's fine, you work with the fully materialized tree just like it's a monorepo. But once you need to submit your changes for review, how does that workflow look? 1. Commit in submodule A, then get it reviewed and merged as SHA 123 2. Update submodule A to 123, get it reviewed 3. Reviewer has feedback on usage of new API in submodule A 4. Make another PR on A, at commit 457. This time don't merge it since reviewer on main repo might have more feedback. Monorepo: 1. Make PR to monorepo 2. Get review feedback 3. Push changes to PR branch 4. Merge 5. Update submodule to 456, push to existing PR ...??
  - foofie 3y ago
    > But once you need to submit your changes for review, how does that workflow look? 1. Post PR to submoduke A. Get it merged. 2. Post PR to the main repo updating it to point to subproject A. Done. The only difference between a monorepo and splitting the repo into submodules is that the main repo's history is coarser and basically tracks the output of integration tests. There is no need to overcomplicate things, and if you need to overthink them anyway then you have far more degrees of freedom to worry about in monorepos.
    - vlovich123 3y ago
      That’s a really slow review process. It also prevents reviewers from seeing the bigger picture of how step 1 manifests in step 2. In practice what I’ve seen you end up with both reviews simultaneously referencing each other in the description and once approved you merge 1 and update the pointer in 2 to point to the new merged commit if it changed. That’s a lot of annoying and sometimes error prone manual bookkeeping that has nothing to do with the engineering work itself
- kristjansson 3y ago
  Anything that cuts across submodule boundaries needs as many MRs as boundaries it crosses, conflicting submodule pointer updates in the main require additional MRs (in the submodules) to resolve and coordination between those MRs. They're basically fine for slowly-moving dependencies, vendoring, etc. but they emphatically do not solve the large-org many-team coordination problems that monorepos are meant to solve. FWIW, git is a great monorepo platform for 1-10m lines of code (Linux, $MY_JOB, ...). It's only the very largest scales (Windows, Google3, ...) or asset heavy cases (ML, game dev) that need special treatment.
sitzkrieg 3y ago
ive never seen positive feedback for submodules before