3 ms·

Is there a reason people prefer a monorepo to submodules? I worked at one place that kept everything in a mercurial mono repo and it was a real pain keeping br

by swiley 6y ago

Is there a reason people prefer a monorepo to submodules? I worked at one place that kept everything in a mercurial mono repo and it was a real pain keeping branches in sync.

saxonww 6y ago
I introduced a submodule at my last job to hold common build code used across multiple repositories. I knew going in that some of our developers didn't really understand git, and were not interested in rectifying that. I won't say the submodule was a disaster, but I definitely paid for it with time spent sitting with people and helping them fix messes. I would do it again but only if I knew I could count on the team to make more than a token effort to understand what a submodule was and how it worked. I would not even consider adding multiple submodules unless I felt like everyone knew exactly how to use them. Another potential source of issues: the submodule remote URI is checked in as part of the .gitmodules file. If your CI system uses a different URI than your developers, you have to work around that. If you change where your source is hosted and you want to check out an old version, you have to figure that out too. That said, I think the most common reason is the same reason some people prefer monorepos in the first place: they perceive the monorepo as simpler, and adding submodules is not simpler. They want to know about and manage 1 repository clone. They want to commit, push, review, and build out of 1 repository. They want to search for stuff in 1 directory tree. They'd also like to do that with 1 tool, ideally 'git'. Nothing really offers that except monorepos.
- mkesper 6y ago
  You can use relative paths for submodule urls.
jayd16 6y ago
The point is so you can do single commit cross project changes. You also have the added benefit of being able to track exact code/dependency versions across all projects. In a many-repo, dependency tracking set up, its an anti-pattern to pin to latest because that can change underneath you and its hard to know what version latest even meant at the time someone committed the dependency. In a submodule setup, you can track exact dependencies but you pin each submodule reference. You can't easily update all downstream references. You can't use latest for reasons above. You also can't make single commits across many projects. In a monorepo set up, you can point to latest (ie whatever is in any given HEAD) and trust that everyone will know exactly what that means now and into the future. Monorepo also opens up some ability for build systems across projects and possibly more insight into company wide dependency tracking.
fanf2 6y ago
Submodules break a lot of other common git features such as switching branches. Instead you have to do something brutal like: git submodule deinit --all --force git clean -dfx git checkout newbranch git submodule update --init --recursive There might be cases where you can do a more lightweight switch, but they probably require iterating over the submodules.

by swiley 6y ago

Is there a reason people prefer a monorepo to submodules? I worked at one place that kept everything in a mercurial mono repo and it was a real pain keeping branches in sync.

saxonww 6y ago

I introduced a submodule at my last job to hold common build code used across multiple repositories. I knew going in that some of our developers didn't really understand git, and were not interested in rectifying that. I won't say the submodule was a disaster, but I definitely paid for it with time spent sitting with people and helping them fix messes. I would do it again but only if I knew I could count on the team to make more than a token effort to understand what a submodule was and how it worked. I would not even consider adding multiple submodules unless I felt like everyone knew exactly how to use them. Another potential source of issues: the submodule remote URI is checked in as part of the .gitmodules file. If your CI system uses a different URI than your developers, you have to work around that. If you change where your source is hosted and you want to check out an old version, you have to figure that out too. That said, I think the most common reason is the same reason some people prefer monorepos in the first place: they perceive the monorepo as simpler, and adding submodules is not simpler. They want to know about and manage 1 repository clone. They want to commit, push, review, and build out of 1 repository. They want to search for stuff in 1 directory tree. They'd also like to do that with 1 tool, ideally 'git'. Nothing really offers that except monorepos.

mkesper 6y ago
You can use relative paths for submodule urls.

jayd16 6y ago

The point is so you can do single commit cross project changes. You also have the added benefit of being able to track exact code/dependency versions across all projects. In a many-repo, dependency tracking set up, its an anti-pattern to pin to latest because that can change underneath you and its hard to know what version latest even meant at the time someone committed the dependency. In a submodule setup, you can track exact dependencies but you pin each submodule reference. You can't easily update all downstream references. You can't use latest for reasons above. You also can't make single commits across many projects. In a monorepo set up, you can point to latest (ie whatever is in any given HEAD) and trust that everyone will know exactly what that means now and into the future. Monorepo also opens up some ability for build systems across projects and possibly more insight into company wide dependency tracking.

fanf2 6y ago

Submodules break a lot of other common git features such as switching branches. Instead you have to do something brutal like: git submodule deinit --all --force git clean -dfx git checkout newbranch git submodule update --init --recursive There might be cases where you can do a more lightweight switch, but they probably require iterating over the submodules.