Hacker News Reader

Comment by anchpop | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

    git config --global --add submodule.recurse=true

will solve most of these issues.

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.

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

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.

fortunately it's trivial to clone a repo and link to the clone

In a dependency of a dependency of a dependency?

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.

The next leftpad debacle is going to be due to a git dependency.

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.

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.

Reply on news.ycombinator.com