31 ms·

The problem, as I see it, is that it was designed for a rather complex/obscure use-case. Most people need only a fraction of that (akin to mercurial subrepo or

• exDM69 15y ago
  > The problem, as I see it, is that it was designed for a rather complex/obscure use-case. Managing software version dependencies is a complex problem and will inevitably have a complex solution, you can't make it any simpler by dumbing it down. If it was simple, there would be even more annoyed people when Git takes a long time checking for new versions in external repositories when doing something unrelated. And finally when the "simple use case" of tracking the remote HEADs and silently updating would give you an incompatible set of dependencies, someone would get furious and write an angry blog post. What most people are asking here (get rid of "submodule update") is solvable by adding a shell alias. Or with the .gitignore and simple clone method discussed in this thread. I don't think "git submodule update" is terrible usability. Complaining about is like complaining about having to "git add" before a commit. Removing that feature would make git worse, not better (albeit a little simpler). And as said earlier, if you don't like the "usability" it's a matter of adding a shell or a git alias to do what you want.