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.
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.
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.
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.
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.
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.
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.
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.
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.
That doesn't make sense. Winter is the best time to invade Russia because you have fresh supplies, you are prepared for winter and you have spring, summer and autumn to secure it.
The mistake is to invade Russia in late summer because the campaign will be prolonged and you will have to secure Russia in winter, with your summer clothing, which is the problem.
*edit: But don't forget about the nuclear bombs and the evilness of war itself. It's never a good idea to invade Russia.
The quote, usually known from the Princess Bride, is actually from Field Marshall Montgomery addressing the House of Lords:
The next war on land will be very different from the last one, in that we shall have to fight it in a different way. Rule 1, on page 1 of the book of war, is: "Do not march on Moscow". Various people have tried it, Napoleon and Hitler, and it is no good. That is the first rule. I do not know whether your Lordships will know Rule 2 of war. It is: "Do not go fighting with your land armies in China". It is a vast country, with no clearly defined objectives.
Montgomery didn't say except in Winter. He said don't do it all.
I’m not sure what you mean by “won”, the Japanese most certainly did not conquer Russia, which is the entire point of this old truth: that the geography and vastness of Russia makes it extremely difficult, if not impossible, to conquer. It’s a very different thing to attack Russia and have them cede territory to you, this has been done many times even by European countries.
Git doesn't compose.