[nrclark]

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

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

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

[pmeunier]

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

[IshKebab]

Yeah I feel the same way. They work quite well but the interface is as typically terrible as you would expect from Git.

[vnorilo]

Try to move one to a new path!

[nrclark]

This "just works" as long as you use `git mv` to do it. Agreed that it's a pile of yuck to try and do it manually though.

[vnorilo]

Not really, at least right here git mv does not fix structure of `.git/modules` and the submodules break. Just tried it again.

EDIT: apparently git on mac is just too old. Time to brew it. https://stackoverflow.com/questions/4604486/how-do-i-move-an...