Is there anything wrong with the submodule architecture itself? My impression is that the data model is fine, but the interface for manipulating them is confusing even by git's standards.
Your impression is correct: They are functionally identical to svn externals that pin to a revision, but require an odd set of commands to update, instead of just being batched in like how "svn up" includes externals.
I've never had a problem with them and don't understand why so many do.
I won't suggest others are referring to the same issues necessarily, but try switching between branches(/commits) when you have submodules. Let alone rebasing etc... they simply don't "just work". You always get some odd vestige of a submodule hanging somewhere that ends up causing problems, either in the index or the .gitmodules or somewhere in .git/ or whatever. Hell, the fact that there are so many places where git submodules are recorded itself has caused me so many headaches.
The most fun is had when a submodule was introduced to replace what was previously an ordinary directory, then you try bisecting across that commit. Qemu's git repo has at least one of these (the slirp/ submodule/directory) which I curse every time I need to bisect something.
Hm, this sounds like a good example of something I never encountered just by chance. Be it svn externals or git submodules, I never string them around the codebase - I put them in a subdirectory that's just for that purpose.
Switching commits and rebasing works like I expect it to. You need to update after switching of course.
I've always assumed the copy in .git/modules is just a cache so I don't have to re-clone the whole submodule if I switch to a commit where the submodule doesn't exist, then switch back.
I don't know if it's the interface or the data model but stuff goes real sideways when you move across the commit boundary where the submodule was added, basically breaking the fluiditiy of git. I think some of this is the files in the .git directory and the filesystem and some is the tools not handling the edge cases.
There are the other parts where really a git clone should be recursive by default pulling the submodules instead of surprising you that oh crap I have to go submodule init or whatever the command is like 50 times.
Exactly so. The problem with submodules isn't the concept itself, it's the lack of transparency. The submodule state should always be kept up to date with the state of the working tree, so that you never end up in a situation where it is stale and out of sync with everything else.
Git LFS has a similar problem, but there it does at least check out the content by default. But even there there have been too many times I've had to manually fetch things, or push things manually to different remotes.
