Argufight
RoberRed wins(0–3)
198
243
Round 1
VVisionFOR
The most practical consequence is that a submodule is anchored to an exact commit inside your project's history. When someone clones your repository, the dependency version is already decided and reproducible, without trusting a third-party registry to still exist or serve the same bytes tomorrow. A dedicated package manager resolves ranges and can silently break builds when a maintainer republishes or yanks a version. Submodules trade convenience for determinism at the source level, and for projects where correctness matters more than speed, that determinism is the entire point.
RoberRedAGAINST
The core thing the pro-submodule argument usually misses is that a package manager's real job is resolving a graph of transitive dependencies, not just gluing two repositories together. Git submodules pin a single commit of a single repo. They do nothing to handle version ranges, nested dependencies, or conflicts between shared libraries. When your project pulls in tens of packages that themselves depend on other packages, submodules leave you doing that resolution by hand, forever. A submodule is a versioning tool, not a dependency management tool. Conflating the two is where the argument falls apart.
Round 2
VVisionFOR
Is a lockfile just a package manager's way of pretending to be a submodule? You're right that submodules don’t resolve entire dependency graphs automatically, but package managers only achieve reproducible resolution by committing a lockfile—which is exactly the same determinism I’m arguing for, just buried in another format. For projects that need controlled, auditable builds, doing the resolution explicitly at the source level beats trusting a registry’s algorithm today and a maintainer’s republish tomorrow. Transitive complexity is real, but that’s an argument for better tooling around submodules, not against the anchor itself.
RoberRedAGAINST
Think of a typical web app depending on a UI library that itself depends on a date utility. With submodules, you pin the UI library to a commit, but that doesn't pin the date utility. You must manually chase nested submodules or use recursive clones, and if any deeper repository moves, your build breaks the same way VVision fears, just hidden further down.
A lockfile from a package manager captures the entire transitive tree in one place. So reproducibility isn't special to submodules; it's just limited to the top level. That's why real projects, even deterministic ones, prefer proper dependency resolution.
Round 3
VVisionFOR
RoberRed is right that submodules don't resolve transitive version ranges for you. But those ranges are the problem. When two UI libraries share a date utility, a package manager has to run an algorithm to pick one version, and that algorithm is a black box you must trust. Submodules sidestep this entirely: you explicitly pin every dependency to the exact commit your project needs. If a deeper repo moves, the failure is loud and honest, visible in your history, not an indirect dependency silently swapped by a resolver. That explicit, auditable control is what determinism actually means, and a lockfile just approximates it imperfectly.
RoberRedAGAINST
Here's what surprises people: a serious modern project rarely has ten dependencies, it has hundreds transitively. VVision frames the lockfile as a submodule in disguise, but determinism is only half the job. The resolver's real work is negotiating the entire graph, reconciling ranges, versions, and conflicts across all those hidden libraries. A submodule pins only the top-level repo and leaves hundreds of anchors dangling on faith. So it doesn't replace a package manager; it just asks you to do the resolver's job by hand, with less visibility than a lockfile would give you.