[nrclark]

Agreed that Git submodules aren't a good tool for the problem of "I want to work in multiple repos at the same time".

It's designed for things like "my project needs to check out pinned versions of these 4 external repos", ideally where the pinned version doesn't move all that often.

Git-submodule is best used as a replacement for the "shell script that clones a bunch of dependencies" pattern, not as a multi-repo workflow coordination tool. And in that context, it works very well.

Imagine you had a CLI tool that tool that consumes some text-file list of repos, commits, and paths. Every repo in the list gets cloned to the path you asked, and each repo's requested hash is checked out. The text-file is controlled in your main Git repo.

That's essentially all that Git-submodule is, except that it's built into Git instead of having to roll your own or introduce another tool dependency. There's also some light integration to handle recursive clones and reporting if the submodule state is dirty.

[Ygg2]

> It's designed for things like "my project needs to check out pinned versions of these 4 external repos",

But I can already do that with Cargo. And it's million times more intuitive.

[nrclark]

Cargo is a great tool if you're writing Rust. Go-get is a great tool if you're writing Go. Npm is a great tool if you're writing Javascript. C/C++ options are all nonstandard and maybe bad.

Git submodules is a "none of the above" tool that handles generic situations where you have one top-level repo that depends on pinned versions of a few other repos.

[Ygg2]

> Git submodules is a "none of the above" tool

So in other words. It's a source versioning tool trying to solve an issue that's better solved by a package manager, and the abstraction mismatch shows.

Like trying to perform eye surgery using rockets.

I'd be ok if Git submodules actually worked (not sorta worked, not "run git submodules update and pray to Linus the issue goes away" worked). It's just that it doesn't. It solves one hard problem, at the expense of making everything else more convoluted.

[Smaug123]

But you can't do it with C!

[Ygg2]

So, you're saying C isn't a Turing complete language and can't port Cargo?

I mean if you are working with toolchain literally designed in the last century, then yes, it's a problem.

[Smaug123]

Guess what - the world is in fact full of such toolchains, many of which are in very widespread use!

[Ygg2]

Maybe write a better toolchain?

[Smaug123]

That's like saying "just use Typescript" when anyone complains about Javascript. The world is drowning in Javascript; it is work to migrate any given instance of Javascript; we are not drowning in labour; so it won't get done.