There is nothing "bad" about submodules. They do what they were intended to do very well. They are often misused because people don't take the time to understand how things work (event at a conceptual level) before diving into it.
I've found submodules most useful when I'm tracking an external dependency that doesn't change often -and- I don't have a dependency management system to lean on.
For example, I have a repository of 100+ various bash utility scripts. One of the scripts depends on another repository with 500MB of data. I don't use it often so I don't need that large repo cloned alongside my bash scripts every time. In this case:
1) The dependency doesn't change often and I like being deliberate when using a new version of that dependency.
2) The dependency is optional and can simply be ignored when using Git's default clone behavior for my repo.
3) Since it's just a bunch of bash scripts, I don't have a package management system to lean on. I use these scripts on multiple *nix distributions.
Could I make it work without Git submodules? Yes. I would have added the dependency to .gitignore and wrote a script to `git clone` the dependency and set it to a specific revision. Submodules just makes that process a lot easier.
You were elaborating on the comment, weren't you? And that comment was quite vague too.
> There is nothing "bad" about submodules.
The difference between "what are uses and misuses" and "what is good and bad" is not enormous. I think you're nitpicking. Plus, there are things that are flat-out bad. It's a human-made program under constant development, after all.
> You were elaborating on the comment, weren't you? And that comment was quite vague too.
What was vague about that comment?
> The difference between "what are uses and misuses" and "what is good and bad" is not enormous.
This is incorrect. The definition of "bad" is something of low quality. Misusing a tool and then calling it low quality is dumb.
> Plus, there are things that are flat-out bad. It's a human-made program under constant development, after all.
What about git submodules is "flat-out bad"?
It's ironic that you're criticizing others' comments on being vague and providing non-answers while you've contributed nothing to the discussion. Maybe educate yourself on technical things and you won't need to waste your time having meta discussions on internet forums. Looks to me like you want to contribute but have nothing of value to say.
Do you want me to grep the changelog for fixed mistakes?
Do you think they fixed all of them, just now, june 2022?
There are mistakes, which are flat-out bad. Trying to fix them is a continuous process that is not complete. And there are probably bad decisions that will be baked in forever, but that's not necessary to prove my point.
> It's ironic that you're criticizing others' comments on being vague and providing non-answers while you've contributed nothing to the discussion.
It's not ironic. One person asks for input. Another person gives a vague answer. I call the answer too vague to be useless. That doesn't make it my job to be specific now. I'm not answering OP. I'm giving feedback on a different answer.
Which is what you were originally doing too, so don't complain that it's not "of value".
And I'm not criticizing submodules here either.
I'll make my argument more clear. The idea that any software has "nothing bad" about it is ridiculous. That's a generic argument for all software. If you really want examples, look at the changelog. But I think it should be obvious. If you think it would even be useful for me to provide an example, then there's probably been a terrible miscommunication.
Every software out there has defects. Bugs, performance issues, UX issues, etc. To assume that anyone in this thread actually means that submodules have no defects whatsoever... well... that's just creating a straw man to tear down because you're grumpy or something.
The issue appears to be with your understanding of what "bad" means in this context. When the OP (and commenter I was responding to) says "bad", they're referring to the overall experience of using git submodules. That specifically does not include the minor fixes/improvements you'd find in a changelog.
By your definition, all software is "bad" because all software has defects in varying degrees. That of course makes the entire conversation pointless and pedantic.
Git submodules work just fine when they're used properly. I've been using them for years without issue and so have many other commenters here. Are there things we (the users of git submodules) would like to see improved? Of course! But that doesn't violate the statement that there is "nothing bad" about submodules in the context of this discussion.
I really hope this helps you navigate conversations with a little more nuance. If not, that's okay too. Have a nice weekend.
> When the OP (and commenter I was responding to) says "bad", they're referring to the overall experience of using git submodules.
Ah, here's the part where things went wrong.
I said "what's good or bad", which is not a judgement of the overall experience. It's the same thing as "uses and misuses" from a different angle.
Talking about what software is better at and worse at is a good response to "why is it bad?". "No it isn't" is mostly a waste of time, especially when a lot of people have bad experiences.
And don't say that the miscommunication is in my mind when you glossed over the word "good" entirely.
> By your definition, all software is "bad"
By my definition, all software has bad elements and bad contexts. And good ones, too. Asking where those lie is not pedantic or pointless at all.
> that doesn't violate the statement that there is "nothing bad" about submodules in the context of this discussion.
If an "overall experience" being good enough means that there is "nothing bad", I'm not the one lacking nuance. You've just obliterated nuance.
