You have a monorepo anyway, and the choice is between dealing with it via wrappers automated or manual wrappers around tools like git (e.g., manually cloning re

You have a monorepo anyway, and the choice is between dealing with it via wrappers automated or manual wrappers around tools like git (e.g., manually cloning relevant repositories and constructing a build environment referencing all the right versions appropriately) or whether you'll use dedicated monorepo tooling. That's still maybe an interesting question, but when appropriately framed it highlights that the real issue is that monorepo tooling may or may not fit your use case well, and you might be better served by hacking together more primitive solutions or making your own tooling. IMO, the major point of the article still stands; git and whatnot are pretty good, and the build/deploy tools interacting with your code are probably terrible, so absent major outside pressures you'll go a long ways figuring out how to leverage git (in a monorepo configuration) against jenkinbuckethubernetes, and that's often much less painful than inevitably figuring out how to marry two ancestrally disjoint codebases.