Submodules aren't perfect and can be really annoying. I tried to avoid them at first.
But if you work with larger projects I think you'll see how they are useful.
For example, some projects might commit their node_modules or composer vendor folder as submodules so that they have an exact snapshot of their dependencies that can be quickly cloned in place and referenced without mixing it with the parent repos source.
Submodules are certainly not the only way to do things with git. Sometimes monorepos or something else makes more sense.
But if you care about maintainability then what are you supposed to do when the majority of your commits are unrelated to your project because you're using git subtree or something similar? Or the majority of your files are also not directly relevant to your project but need to be there?
What about stuff like optional tests or maintenance scripts or even binary dependencies that you want to have closely associated with your project but don't want to clone every time?
My thinking is that the porcelain is incomplete but very open. The way submodules are represented can be added on to.
And the plumbing is consistent enough that you easily script around it.
You should check out the Datalad project to see some really clever usage of submodules.
And the url key can be annoying; I usually try to use relative paths in my .gitmodules folder when possible. You're actually free to use remote helpers and relative paths to get around hard a github url into it.
You can also embed and read arbitrary keys from your .gitmodules file with git-config -f which is really useful. You don't even have to use a .gitmodules file, in theory.
Well indeed. I think the ultimate point is that Git is severely lacking here. There are clear use cases (you listed some) that drive people to submodules or LFS, but they are both shitty solutions.
We need Git (or something else) to provide a third solution that actually works. I'm really hoping that JJ realises that this is a problem that needs to be solved but I'm not holding my breath.
I think submodules are good enough for what they do and there's room in Git's model for forward development and it's also flexible enough that third party tools can piggyback on it.
Like Git in general it's a bit of a pain till you practice with it more.
Git can do some amazing stuff, I use it for data as well as code.
Comments
Submodules aren't perfect and can be really annoying. I tried to avoid them at first.
But if you work with larger projects I think you'll see how they are useful.
For example, some projects might commit their node_modules or composer vendor folder as submodules so that they have an exact snapshot of their dependencies that can be quickly cloned in place and referenced without mixing it with the parent repos source.
Submodules are certainly not the only way to do things with git. Sometimes monorepos or something else makes more sense.
But if you care about maintainability then what are you supposed to do when the majority of your commits are unrelated to your project because you're using git subtree or something similar? Or the majority of your files are also not directly relevant to your project but need to be there?
What about stuff like optional tests or maintenance scripts or even binary dependencies that you want to have closely associated with your project but don't want to clone every time?
My thinking is that the porcelain is incomplete but very open. The way submodules are represented can be added on to.
And the plumbing is consistent enough that you easily script around it.
You should check out the Datalad project to see some really clever usage of submodules.
And the url key can be annoying; I usually try to use relative paths in my .gitmodules folder when possible. You're actually free to use remote helpers and relative paths to get around hard a github url into it.
You can also embed and read arbitrary keys from your .gitmodules file with git-config -f which is really useful. You don't even have to use a .gitmodules file, in theory.
Well indeed. I think the ultimate point is that Git is severely lacking here. There are clear use cases (you listed some) that drive people to submodules or LFS, but they are both shitty solutions.
We need Git (or something else) to provide a third solution that actually works. I'm really hoping that JJ realises that this is a problem that needs to be solved but I'm not holding my breath.
What problem are you trying to solve exactly?
I think submodules are good enough for what they do and there's room in Git's model for forward development and it's also flexible enough that third party tools can piggyback on it. Like Git in general it's a bit of a pain till you practice with it more.
Git can do some amazing stuff, I use it for data as well as code.