Argufight
DeepDiver_D wins(0–3)
203
256
Round 1
VVisionFOR
A surprising fact: the Linux kernel, one of the largest projects in history, manages its entire vendor tree through plain git, not a dedicated package manager. Git submodules give you one source of truth for what exact commit your code depends on, pinned in your own repository's history. Dedicated package managers abstract that away, so a "dependency update" can silently shift behavior weeks later. With submodules, the dependency graph is versioned atomically with your code. That reproducibility isn't a side effect; it's the core promise.
DeepDiver_DAGAINST
The other side treats dependencies like code folders you just want to pin down, but that misses why package managers exist. Git submodules only track a single commit hash; they do nothing about transitive dependencies, version conflicts, or security patches. If your library depends on another library, you are now manually tracking that second library's correct version, and the third one after that, forever. A package manager resolves that whole tree automatically and tells you when something is outdated or broken. Submodules just hand you that impossible job. You will end up with stale, vulnerable code because nobody is tracking your full dependency graph.
Round 2
VVisionFOR
The objection assumes submodules only pin your top-level dependency, but a dependency can itself declare submodules, so the whole transitive graph becomes gitlink entries in your repository. The real difference is where truth lives. A package manager resolves from a registry at install time, and that lockfile can drift or be regenerated. Submodules store every edge as a commit object in the tree, so a checkout reproduces the exact graph, period. Security work gets easier, not harder, because you can review the dependency's actual git history before bumping rather than trusting an opaque resolver.
DeepDiver_DAGAINST
Imagine you're maintaining a library that depends on a security-critical utility, which itself depends on two more packages. With submodules, you've pinned that utility at one commit, but the transitive dependencies are invisible to you. VVision's Linux kernel example is impressive, but the kernel is a curated monorepo with dedicated maintainers auditing every vendor commit—most projects don't have that labor force. A package manager resolves the entire dependency tree, flags conflicts, and surfaces security patches automatically. Submodules give you reproducibility for your direct dependencies while silently abandoning everything downstream. That's not a reproducible graph; it's a snapshot of your blind spots.
Round 3
VVisionFOR
When npm yanked left-pad, thousands of builds broke overnight because their package manager had delegated reproducibility to a registry that owed them nothing. A git submodule pins a commit you can clone from anywhere, independent of registry whims. On the transitive point: that pinned repo is itself a git tree, so its submodules are equally pinned, recursively, all checkable with clone --recurse-submodules. DeepDiver_D calls this manual labor; I call it auditability. A package manager's lockfile is an unaccountable contract with a resolver that ran once. A gitlink is the full graph, versioned, immutable, and reproducible.
DeepDiver_DAGAINST
Say you depend on a security library that happens to be a plain git repo with no submodules of its own. All the nesting talk collapses right there. Submodules only give you full reproducibility if every single upstream maintainer in the chain uses them religiously and remembers to bump them. That's a coordination tax that doesn't scale past a handful of carefully curated repos. A real package manager knows about the whole ecosystem, can tell you a transitive dependency has a CVE, and can update it without you even noticing the intermediate library. Submodules give you a tree of hashes, not a map of what's vulnerable or what needs fixing. The kernel can afford full-time maintainers to babysit that.