Josh: Get the advantages of a monorepo with multirepo setups

Re:Josh: Get the advantages of a monorepo with multirepo setups by derefr on Thursday July 15, 2021 @12:17PM (#27846440)

Git submodules already solve that problem, though. As does publishing all the core libraries etc. as language-ecosystem packages on a private package namespace or internal corporate package repository, and then resolving/locking the language-package dependencies to specific tags/refs with a lockfile that gets committed to the downstream repo.

These are the "obvious" solutions to this problem, the first ones the average software architect would reach for. What would lead them to ignore these options and choose a monorepo instead, if not for what I mentioned above — the ability to make atomic changes to cross-cutting concerns?

[ Parent | on HN ]

Re:Josh: Get the advantages of a monorepo with multirepo setups by justaguy88 on Thursday July 15, 2021 @12:48PM (#27846791)

Git submodules have an annoying attribute: double commit

First you commit/push to one repository

Then you update the submodule pointer in the parent repository

[ Parent | on HN ]

Re:Josh: Get the advantages of a monorepo with multirepo setups by chiefalchemist on Thursday July 15, 2021 @12:44PM (#27846760)

I've resisted - for too long? - submodules as I've always heard they can be problematic; that the actual implementation isn't quite what I should be.

[ Parent | on HN ]

Re:Josh: Get the advantages of a monorepo with multirepo setups by zerkten on Thursday July 15, 2021 @01:34PM (#27847397)

>> These are the "obvious" solutions to this problem, the first ones the average software architect would reach for.

They would have been, except the experience working with them was somewhat problematic for those who have been down this path, and the message that many devs have received is to avoid them. I kind of agree with going to submodules, but confidence doesn't seem to have been rebuilt.

[ Parent | on HN ]