1. 3

  2. 1

    I think most of the issues the author has could be solved by a sparse git checkout. Basically you only fetch one subdirectory of the whole got repo. It’s faster, plus allows for smaller checkouts.

    There is definitely thruth in the objections though, a monorepo has disadvantages too. What I did was create the monorepo and do a split to commit to the individual repo’s again. It allowed us to see if it was a match for us without changing our tooling as the individual repos where being kept up to date too. It helped us a lot to PoC it fast and don’t waste too much time.

    1. 1

      That would definitely help to improve the git performance if the repository’s history is too big, but there are other problems such as executing only the tests for checking the correctness of the changed parts that are hard to solve. Big companies using a monorepo model such as Facebook and Google have invested a lot of effort in designing tools (and even its own build system, see https://bazel.build/ and https://buckbuild.com/) for an efficient monorepo.