Hacker News Reader

Comment by Too | Hacker News Reader

"Git's submodules are so universally derided that there's practically an entire industry devoted to providing alternatives for managing dependencies." Stop right there and repeat after me:

Git is not a dependency manager, git is not a dependency manager, git is not a dependency manager, git is not a dependency manager.

Seriously, use the package manager provided by your build system. Some of them can point to git repos if you don't have a proper package registry, this is a better solution than plain submodules, for many reasons; Transitive dependencies, diamond dependencies, semantic versionion, can't forget to submodule update --recursive, etc, etc.

View on HN

>Seriously, use the package manager provided by your build system.

Git is about source code. How would you use the package manager to manage source code?

The original author seems to he worried that some part of the system is not being updated to the newest available source before being built. I don't know of any system that would somehow automate that process.

The suggested submodule system might work as long as branch names don't change. But in real life they do change, old branches go out of maintenance. So in the end there must be a human making sure you don't miss anything.

> The original author seems to he worried that some part of the system is not being updated to the newest available source before being built. I don't know of any system that would somehow automate that process.

Subversion with svn:external does exactly this by default, and generally you only peg a revision in an external dependency when you tag for release.

> this is a better solution than plain submodules, for many reasons; Transitive dependencies, diamond dependencies, semantic versionion, can't forget to submodule update --recursive, etc, etc.

Well, one could argue that diamond dependencies are just bad design, transitive dependencies are just submodules of submodules, leading to conclusion that using submodules is like pinning entire dependency tree to a particular commit. So for a given commit there is only one way to download entire tree that is cryptographically secure, without trusting third parties.

I still wouldn't recommend submodules if your build system have packages but it's an interesting idea nonetheless.

If I depend on library A and B which both depend on the standard library, I have a diamond dependency. How is that bad design?

Standard library is usually an implicit dependency. Which package manager makes you explicitly name and version std lib?

Cabal is one example, which requires packages like `base` to be specified explicitly.

Cabal runs a dependency solver to satisfy most dependencies, but for compiler-provided things like `base` it simply checks whether or not the requirement is satisfied by the compiler being used (if not, it bails out).

I think C/C++ developers would love nothing more, but there is no standard package manager for those languages.

Reply on news.ycombinator.com