3 ms·

git submodules is just /begging/ for tooling. On the surface, the commands are fairly verbose. And (as the article pointed out) the documentation on it could u

git submodules is just /begging/ for tooling. On the surface, the commands are fairly verbose. And (as the article pointed out) the documentation on it could use some love. However the biggest problem I have encountered while using it, is that what code I actually have checked out is opaque without doing the song and dance of actually checking out each submodule & inspecting the dir. This sucks when evaluating the codebase without cloning e.g. in code review on GitLab/GitHub. And the commands/UX for updating them is just painful and error prone. Really, the difference between putting something in a git submodule and putting something in a private npm/maven/etc. repo is that I can look at a file and read: my-dependency v1.1.5 And my human-brain can kind of know what that means. Whereas if I look at a repo with a submodule, I just see a URL and a SHA. And while actually I think that this is a better model for keeping track of versions, it's terrible from a UX perspective. There's also a whole host of tooling around your languages chosen artifact/package/dependency management that git submodules don't have yet. It's often supported by the same tools we use for compiling and other task running. Git submodules require another thing that lives outside of that ecosystem. I kind of wish that a mainstream language would just adopt git submodules as part of their de facto package management strategy and build the tools on top of it we need to make it livable.

CMCDragonkai 8y ago
You can use tags for human readable names of commit hashes. But never rely on tags for security!
- lilactown 8y ago
  I don't think the tag actually is a property of the submodule steps itself (as in, it's not written in the .gitmodules), but yes you can manually check out a tag.
speedplane 8y ago
> I kind of wish that a mainstream language would just adopt git submodules as part of their de facto package management strategy and build the tools on top of it we need to make it livable. Every language has a package management system already. Git should be made easier to use, not harder. I see the utility of submodules to power users, but they're not so necessary at all, but increase the complexity of git by adding yet another abstract concept. Love you git, but you should be working on removing features, not adding them.
- lilactown 8y ago
  We're getting off on a tangent, but I actually think that dependency management makes way more sense to do in a VCS than some other tool provided by a specific language. Look at the cluster that is dependency management in JavaScript, Go, etc. Every ecosystem is solving the same problem over and over, and languages can live and die by the quality and capabilities of their package management system. It also sucks once you start building projects that are multi-language/ecosystem. It's why so many front-end technologies have just sucked it up and adopted NPM, because it has the most market share and continuing to bifurcate the package ecosystem is too cumbersome for consumers. It would be much better to solve it /once/, with a tool that provides the lower level constructs. Then tools could be built on top of that to serve specific needs & improve the UX. Maybe git submodules could be that? Whether it could or not, though, I do think that providing the ability to manage the versions of my dependencies in the same tool that I manage the versions of my own project... makes a lot of sense!
  - chriswarbo 8y ago
    Whilst it's certainly a case of https://xkcd.com/927 https://xkcd.com/927 I find that Nix is very good for what you describe; there's also Guix but I've yet to use it. I think of them as "Make done right".
chiefalchemist 8y ago
"it's terrible from a UX perspective." Agree. The general concept is sound and needed but the execution / implementation is subpar.
- speedplane 8y ago
  I think git can easily claim the the award for terrible UX. It was intended for Linux Kernel development, not hobbyists or even medium size teams that need to put something together.
  - chiefalchemist 8y ago
    Absolutely. It's a great idea. It's a great tool. But it needs a serious makeover to the point that it's not exactly the right tool for modern software product dev / engineering. Providing software solutions is difficult enough. Your tools shouldn't add friction.

CMCDragonkai 8y ago

You can use tags for human readable names of commit hashes. But never rely on tags for security!

lilactown 8y ago
I don't think the tag actually is a property of the submodule steps itself (as in, it's not written in the .gitmodules), but yes you can manually check out a tag.

speedplane 8y ago

> I kind of wish that a mainstream language would just adopt git submodules as part of their de facto package management strategy and build the tools on top of it we need to make it livable. Every language has a package management system already. Git should be made easier to use, not harder. I see the utility of submodules to power users, but they're not so necessary at all, but increase the complexity of git by adding yet another abstract concept. Love you git, but you should be working on removing features, not adding them.

lilactown 8y ago
We're getting off on a tangent, but I actually think that dependency management makes way more sense to do in a VCS than some other tool provided by a specific language. Look at the cluster that is dependency management in JavaScript, Go, etc. Every ecosystem is solving the same problem over and over, and languages can live and die by the quality and capabilities of their package management system. It also sucks once you start building projects that are multi-language/ecosystem. It's why so many front-end technologies have just sucked it up and adopted NPM, because it has the most market share and continuing to bifurcate the package ecosystem is too cumbersome for consumers. It would be much better to solve it /once/, with a tool that provides the lower level constructs. Then tools could be built on top of that to serve specific needs & improve the UX. Maybe git submodules could be that? Whether it could or not, though, I do think that providing the ability to manage the versions of my dependencies in the same tool that I manage the versions of my own project... makes a lot of sense!
- chriswarbo 8y ago
  Whilst it's certainly a case of https://xkcd.com/927 https://xkcd.com/927 I find that Nix is very good for what you describe; there's also Guix but I've yet to use it. I think of them as "Make done right".

chiefalchemist 8y ago

"it's terrible from a UX perspective." Agree. The general concept is sound and needed but the execution / implementation is subpar.

speedplane 8y ago
I think git can easily claim the the award for terrible UX. It was intended for Linux Kernel development, not hobbyists or even medium size teams that need to put something together.
- chiefalchemist 8y ago
  Absolutely. It's a great idea. It's a great tool. But it needs a serious makeover to the point that it's not exactly the right tool for modern software product dev / engineering. Providing software solutions is difficult enough. Your tools shouldn't add friction.