I've found git submodules to achieve the best of both worlds: dependency sources are readily available as part of my own projects, and it's straightforward to update them if need be. The only wrinkle is that a plain ol' `git clone` doesn't pull everything by default, but can be worked around with a clarifying note in the README or by making it part of the build process.
Obviously there's a time and a place - if a language or build system I'm using includes dependency retrieval/resolution for projects, then that's usually my preference. But for things like C (and, currently, Zig) that lack such things, vendoring with git submodules is pretty nice.
There’s a lot of submodule haters out there. I think the majority of haters are people who tried to actually do work within submodules. That’s a recipe for conflicts. It’s probably best to go into the submodule directory, checkout a specific tag or commit, go up one directory, and commit.
3 comments
[ 2.8 ms ] story [ 15.5 ms ] threadObviously there's a time and a place - if a language or build system I'm using includes dependency retrieval/resolution for projects, then that's usually my preference. But for things like C (and, currently, Zig) that lack such things, vendoring with git submodules is pretty nice.
This is a good blog post about submodule gotchas: https://www.jannikbuschke.de/blog/git-submodules/