[Ygg2]

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.

[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?

[nrclark]

> 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).

[Ygg2]

> That's because git-submodule doesn't really interconnect across repos (not much anyways). A submodule is a completely separate repo

Yeah. I know. Submodules is the file that has link to external repo, and hash to submodule current Head/current version.

----

I think you misunderstood my example.

Ss14 has RobustToolbox submodule.

I changed something unrelated in ss14 on branch fix. But master updates submodules.

I rebase fix on master.

Git bash notes Robust has changed. Nothing else does.

Why? How?

This is just some awful implementation details leaking the flimsy Git submodules abstraction.