Out of curiosity, why the hate for git submodules? They've worked really well for me over the years. They solve the problem of "pin a specific version of some external 3rd-party repo" really nicely.
The only complaint I have is that the git-submodule CLI has unintuitive syntax. But this is Git after all, so it's par for the course. :v
Because they merely make really hard things hard and simple things painful. They solve a problem (albeit one that can be better solved by a decent package manager like Cargo/NPM).
And in return, basic operations like merge/rebase start breaking in unintuitive ways.
E.g., I work on repo ss14 that has submodules RobustToolbox, but never modify them in my PR.
I rebase my changes. I have changes in RobustToolbox that are only visible in Git Bash. Other Git clients show no changes... Ofc `git submodules update --recursive` might help or something, but it made a simple operation more complicated.
And that's if I didn't change the submodule. If I did, merging/rebasing becomes its own, separate nightmare.
> They solve the problem of "pin a specific version of some external 3rd-party repo" really
With Cargo/NPM you can pin your dependencies to some version you control like a fork or a local directory, making submodules non-necessary.
And unlike submodules, they don't require you to modify your workflow to sprinkle `git submodule update` everywhere.
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.
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.
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.
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.
> And in return, basic operations like merge/rebase start breaking in unintuitive ways.
I just haven't had the same experience at all. Could we work through a specific example?
> I rebase my changes. I have changes in RobustToolbox that are only visible in Git Bash. Other Git clients show no changes.
That's because git-submodule doesn't really interconnect across repos (not much anyways). A submodule is a completely separate repo, with its own stage, commit history, etc. It doesn't even know that it's a being used as a submodule.
Committing/merging/rebasing in your submodule doesn't change the parent. And committing/merging/rebasing in your parent doesn't change the submodule (aside from maybe what commit is checked out).
> They solve the problem of "pin a specific version of some external 3rd-party repo" really nicely.
My understanding is that they sound to many users like you could do more with them, such as making your repository modular, where in fact if you do that, you run into all sorts of problems.
The only complaint I have is that the git-submodule CLI has unintuitive syntax. But this is Git after all, so it's par for the course. :v