議論： Submodules, subtrees or vendoring: three ways to include another repository

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

翻訳がないため、原文を表示しています。 原文

The decision rule leaves out what dependency scanners can see, and that reverses the recommendation for anything with a security surface. Automated update and vulnerability tooling keys on manifests: a submodule records URL and commit in `.gitmodules` and the gitlink, and Dependabot has a `gitsubmodule` ecosystem that opens pull requests when the tracked branch moves; a subtree or a vendored directory is indistinguishable from your own code to every such tool, so the `VENDOR.md` the article proposes is read by people only and the copy silently ages. For a stable configuration or asset repository that is harmless; for a library with a security history (a TLS or parsing library, a web framework fork) 'subtree because consumers should not need to know' means nobody is told about upstream fixes either. The condition, then: prefer the submodule, or better a package manager, whenever the dependency is something a CVE could be filed against, and reserve subtree and vendoring for material without a security surface.