4 ms·

I think if git submodules were architectured differently, they could have been a really interesting solution for package management. In fact my last place of wo

I think if git submodules were architectured differently, they could have been a really interesting solution for package management. In fact my last place of work uses a layer on top of submodules as part of their internal package manager. I think they could be really special but unfortunately are now sort of relegated to history.

jayd16 6y ago
Actually, a lot of dependency managers are starting to accept git repos as dependency sources with pinned hashes as versions. Works out pretty well.
- ss3000 6y ago
  In practice the biggest issue I've found with git+pinned hashes as dependencies is most public sources of remote git repositories allows the repository to be taken down by the author at any time, i.e. an author can turn a public github repo private or simply delete it at will. Whereas most public package registries generally don't allow removal of publicly published packages outside of special circumstances, so the references will be more durable.
  - greggman3 6y ago
    fortunately it's trivial to clone a repo and link to the clone
    - brylie 6y ago
      In a dependency of a dependency of a dependency?
      - slavik81 6y ago
        That's a pain. It's the same problem as a class that constructs a particular object that you want to customize. The solution is also the same: dependency injection.
  - divs1210 6y ago
    The next leftpad debacle is going to be due to a git dependency.
- closeparen 6y ago
  I wish they didn't. Git clone is very slow relative to downloading a tarball. Glide/Dep would take tens of seconds to download what amounted to a few megabytes.
slavik81 6y ago
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.
- grogenaut 6y ago
  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.
  - rleigh 6y ago
    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.
- Izkata 6y ago
  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.
  - mehrdadn 6y ago
    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.
dreamcompiler 6y ago
Completely agree. It's probably possible to create a "monadic" DVCS, but I expect it would have to be designed for composition from the outset, rather than having composition grafted on as an afterthought.

jayd16 6y ago

Actually, a lot of dependency managers are starting to accept git repos as dependency sources with pinned hashes as versions. Works out pretty well.

ss3000 6y ago
In practice the biggest issue I've found with git+pinned hashes as dependencies is most public sources of remote git repositories allows the repository to be taken down by the author at any time, i.e. an author can turn a public github repo private or simply delete it at will. Whereas most public package registries generally don't allow removal of publicly published packages outside of special circumstances, so the references will be more durable.
- greggman3 6y ago
  fortunately it's trivial to clone a repo and link to the clone
  - brylie 6y ago
    In a dependency of a dependency of a dependency?
    - slavik81 6y ago
      That's a pain. It's the same problem as a class that constructs a particular object that you want to customize. The solution is also the same: dependency injection.
- divs1210 6y ago
  The next leftpad debacle is going to be due to a git dependency.
closeparen 6y ago
I wish they didn't. Git clone is very slow relative to downloading a tarball. Glide/Dep would take tens of seconds to download what amounted to a few megabytes.

slavik81 6y ago

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.

grogenaut 6y ago
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.
- rleigh 6y ago
  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.
Izkata 6y ago
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.
- mehrdadn 6y ago
  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.

dreamcompiler 6y ago

Completely agree. It's probably possible to create a "monadic" DVCS, but I expect it would have to be designed for composition from the outset, rather than having composition grafted on as an afterthought.