|
|
|
|
|
|
by delta_p_delta_x
771 days ago
|
|
|
> This is not very realistic. I don't want to become a package maintainer of somebody else's library. Fair enough; then maybe ask the library developer nicely if they could add vcpkg support. Many C++ libraries de-facto support CMake and vcpkg because these have reached critical mass over the past half-decade or so. I'd say submodules are worse in every metric—you still have to maintain someone else's library (imagine a CVE patch comes through, for instance); submodules themselves are so fragile that they can break your own repo, requiring a full delete + re-clone, and it leads to 'I have this code, I can now make changes to it' which makes updating even harder. |
|
|
I wouldn't call `git pull` maintaining a library.
> it leads to 'I have this code, I can now make changes to it
I would say this is a big advantage! Probably one of the few areas where submodules are better than e.g. crates/pypi. It's great for fixing bugs for example. You can fix bugs in Rust crates you use, by using a special override in Cargo.toml, and I assume pip/NPM support that somehow took, but it is more of a pain.
You're absolutely right that submodules are fragile. But they work well enough that people still use them.
> requiring a full delete + re-clone
I've got pretty close to that but actually I've been able to get out of every submodules breakage that I got into. Did require some magic commands I found in a mailing list somewhere though which isn't fun.
I've had zero problems with stability though if you avoid these two features:
* Worktrees, which sucks because worktrees are great
* git checkout --recurse-submodules (or submodule.recurse). This is just fundamentally broken and has been forever.