[glandium]

Probably unpopular opinion: git submodules are just fine. They're "just" lacking a consistent UI. They have improved over the years, but the default config sucks because the defaults emulate the original, awful, UX. With proper configuration, it's much better, although there are still pain points (like rebase conflicts in non-submodule parts messing things up if you don't git submodule update)

[dotancohen]

Can we see your `git config -l`? I sparingly use git submodules, and don't really suffer from any of the common issues as I have a very strict update routine, but I'd love to see where things could be improved.

[glandium]

I'm on mobile, so I don't have that, but search for submodule in the git-config manual page.

[vilunov]

If they don't have a consistent UI and emulate the original awful UX, then in what aspect are they nice?

They have a ton of problems in my experience, a few off the top of my head:

- They force the specific repo url, e.g. ssh github even if you prefer to clone by http.

- Pulling from remote becomes difficult when submodules change, e.g. when a submodule is merged into main repo and becomes a proper subdir.

- git commands such as `git checkout -- .` don't work properly on them and I don't see how configs could change that.

[dcan]

For your first point, does ../../user/repo.git not work? I have a self hosted GitLab and that’s how I’ve specified all my submodules and it survived a top-level url change (with a new clone or changing the origin)

[chipdart]

> Probably unpopular opinion: git submodules are just fine. They're "just" lacking a consistent UI.

I second the sentiment. Git submodules work just fine. The UX could use some work. It baffles me why bolting on convoluted tools is considered a preferable alternative.

[__m]

What I don't like about submodules is that they are centralised, you can't just easily migrate to another server without having them still point to the old one, the urls are version controlled. I since then moved to packages.