> The monorepo problem: git has difficulty dividing the codebase into modules and joining them back

Can anyone explain this one? I use monorepos everyday and although tools like precommit can get a bit messy, I've never found git itself to be the issue?

▲

gritzko 13 hours ago | parent | next [-]

Based on my personal experience, big-corp monorepos have all features of a black hole: they try to suck in all the existing code (vendor it) and once some code starts living in a monorepo, there is no way to separate it as it becomes entangled with the entire thing. There is no way to "blend it in", so to say.

This subject deserves a study of its own, but big-big-tech tends to use other things than git.

	▲	ongy 12 hours ago \| parent \| next [-]
		That black hole behavior is a result of corporate processes though. Not a result of git. Business continuity (no uncontrolled external dependencies) and corporate security teams wanting to be able to scan everything. Also wanting to update everyone's dependencies when they backport something. Once you got those requirements, most of the benefits of multi-repo / roundtripping over releases just don't hold anymore. The entanglement can be stronger, but if teams build clean APIs it's no harder than removing it from a cluster of individual repositories. That might be a pretty load bearing if though.
	▲	rbsmith 12 hours ago \| parent \| prev [-]
		> there is no way to separate it There is git subtree --help May get complicated at the edges, as files move across boundaries. It's a hard problem. And for some subset of those problems, subtree does give a way to split and join.

▲

conartist6 13 hours ago | parent | prev | next [-]

Let's say I want to fork one of your monorepo modules and maintain a version for myself. It's hard. I might have to fork 20 modules and 19 will be unwanted. They'll be deleted, go stale, or I'll have to do pointless work to keep them up to date. Either way the fork and merge model that drives OSS value creation is damaged when what should be small, lightweight focused repos are permanently chained to the weight of arbitrary other code, which from the perspective of the one thing I want to work on is dead weight.

You can also just tell that monorepos don't scale because eventually if you keep consolidating over many generations, all the code in the world would be in just one or two repos. Then these repos would be so massive that just breaking off a little independent piece to be able to work on would be quite crucial to being able to make progress.

That's why the alternative to monorepos are multirepos. Git handles multirepos with it's submodules feature. Submodules are a great idea in theory, offering git repos the same level of composability in your deps that a modern package manager offers. But unfortunately submodules are so awful in practice so that people cram all their code into one repo just to avoid having to use the submodule feature for the exact thing it was meant to be used for...

▲

zelphirkalt 12 hours ago | parent [-]

Hm, I never had much issues with submodules. It seems just to be something that when one has understood it, one can use it, but it might seem scary at first and one needs to know, that a repo uses submodules at all.

	▲	conartist6 10 hours ago \| parent [-]
		Submodule-based multirepos still have a tiny fraction of the adoption that monorepos do. Tooling support is quite poor by comparison.

▲

EPWN3D 8 hours ago | parent | prev | next [-]

I think a lot of people misunderstand what git really is for large software organizations. It's not their version control system. It's the set of primitives on top of which their version control is built.

Monorepos are one such VCS, which personally I don't like, but that's just me. Otherwise there are plenty of large organizations that manage lots of git repositories in various ways.

Replacing git is a lot like saying we should replace Unix. Like, yeah, it's got its problems, but we're kind of stuck with it.

▲

dist-epoch 13 hours ago | parent | prev | next [-]

For example there is no easy way to create a "localized" branch - this branch is only allowed to change files in "/backend", such that the agent doesn't randomly modify files elsewhere. This way you could let an agent loose on some subpart of the monorepo and not worry that it will break something unrelated.

You can do all kinds of workarounds and sandboxes, but it would be nice for git to support more modularity.

	▲	zelphirkalt 12 hours ago \| parent [-]
		Sounds like a submodule with restrictions for push access managed on the repo level of the submodule.

▲

PunchyHamster 13 hours ago | parent | prev [-]

The author doesn't know how to use git or how git works.

If he knew how to use it, he'd be annoyed at some edge cases.

If he knew how it works, he'd know the storage subsystem is flexible enough to implement any kind of new VCS on top of it. The storage format doesn't need to change to improve/replace the user facing part

▲

gritzko 13 hours ago | parent [-]

Joe Armstrong had a beautiful LEGO vs Meccano metaphor. Both things are cool and somewhat similar in their basic idea, but you cannot do with LEGO what you can do with Meccano and vice-versa. Also, you can not mix them.

	▲	zelphirkalt 12 hours ago \| parent \| next [-]
		But you could create some parts that are enabling you to combine them easily. Which is what you could do with software. Write an adapter of sorts.
	▲	fragmede 12 hours ago \| parent \| prev [-]
		Sure you can. Hot glue, E6000, duct tape. This is to say, git's pack format has its shortcomings.