5 ms·

Often there are implicit dependencies between (versions of) the many repos. E.g. where I work, it was decided to put test data in a separate from the code (to k

Often there are implicit dependencies between (versions of) the many repos. E.g. where I work, it was decided to put test data in a separate from the code (to keep the latter repo small in size). But now, when you add a new test case, it will fail on older versions of the code. With a monorepo, you can always check out a consistent version of all parts.

oconnor663 6y ago
And when your CI fails, it blames to a specific commit, rather than "the commit that triggered it, plus any commit in a dependency repo around the same time." And if you need to maintain old release branches, each one is a single branch, and your tooling doesn't need to know anything special about what branches of other repos to check out. And `git bisect` works. All of these things are possible without a monorepo, by using higher-level tooling to manage the relationship between repos. It could be `git submodules`, or Repo, or whatever. But all of those things have their own downsides.
- pierrebai 6y ago
  git submodules tracks the version of the sub repos. So if you organize that your releases are a master repo with all needed repos as sub-modules, your sub-repo version tracking is already done fr you. All that while still allowing sub-repo to move forward faster than other repos. With a mono-repo, you can only allow some sub-system to go forward faster than others by making them live permanently in separate branches. Basically, in monorepo you have to use branches to do what separate repo do normally for free. (Then there is the issue that with a monorepo, any screw up screws everybody. You're all on the same boat, all the time.)
  - leethargo 6y ago
    Yeah, we have set up a "parent" repo with git submodules for all the individual repos. But it was an afterthought and our workflow has not really caught up to the new possibilities.

oconnor663 6y ago

And when your CI fails, it blames to a specific commit, rather than "the commit that triggered it, plus any commit in a dependency repo around the same time." And if you need to maintain old release branches, each one is a single branch, and your tooling doesn't need to know anything special about what branches of other repos to check out. And `git bisect` works. All of these things are possible without a monorepo, by using higher-level tooling to manage the relationship between repos. It could be `git submodules`, or Repo, or whatever. But all of those things have their own downsides.

pierrebai 6y ago
git submodules tracks the version of the sub repos. So if you organize that your releases are a master repo with all needed repos as sub-modules, your sub-repo version tracking is already done fr you. All that while still allowing sub-repo to move forward faster than other repos. With a mono-repo, you can only allow some sub-system to go forward faster than others by making them live permanently in separate branches. Basically, in monorepo you have to use branches to do what separate repo do normally for free. (Then there is the issue that with a monorepo, any screw up screws everybody. You're all on the same boat, all the time.)
- leethargo 6y ago
  Yeah, we have set up a "parent" repo with git submodules for all the individual repos. But it was an afterthought and our workflow has not really caught up to the new possibilities.