4 ms·

Very good article. The question is, will it ever be fixed? As it stands submodules don't even work sanely for the most trivial use-case of tracking a (slow cha

by moe 15y ago

Very good article. The question is, will it ever be fixed? As it stands submodules don't even work sanely for the most trivial use-case of tracking a (slow changing) vendor-repo. Whoever designed this (Linus?) had a real brainfart here.

harshreality 15y ago
I wonder. How difficult can it be to mimic mercurial's subrepos? http://blog.codekills.net/2011/07/14/nested-repository-handling-in-git-and-mercurial/ http://blog.codekills.net/2011/07/14/nested-repository-handl...
- moe 15y ago
  Yes! That should be built straight into git. The abstraction leaks are no worse than with submodules (it's just making different trade-offs) but the usability is so much more sane, it's not funny. The importance of having this in core-git can not be overstated. When it's not in core then it's not getting used. Case in point: count the number of projects on github using one of the external training wheels (subtree etc.). Submodules has proven inadequate for reality (again: count the number of subprojects on github). I wish one of the core-dev's would make a kickstarter for a solution...
exDM69 15y ago
> As it stands submodules don't even work sanely for the most trivial use-case of tracking a (slow changing) vendor-repo. That is not the use case it was designed for. And submodules still work just fine for that. The fact that you have to do a separate submodule update does not make it broken. In fact, it makes it better when you start thinking about all the corner cases there are. If you truly want to build a software out of subrepositories, you need to have a sane way of tracking working sets of revisions of all the submodules there are. And that is what git submodules does. If you were blindly tracking the head of a repository, it would be useful _only_ for the use case you mentioned. Tracking slowly changing external vendor repos. That would be a whole lot less useful.
- moe 15y ago
  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 even svn externals) and don't want to be exposed to all the corner cases and terrible usability.
  - 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.

by moe 15y ago

harshreality 15y ago

I wonder. How difficult can it be to mimic mercurial's subrepos? http://blog.codekills.net/2011/07/14/nested-repository-handling-in-git-and-mercurial/ http://blog.codekills.net/2011/07/14/nested-repository-handl...

moe 15y ago
Yes! That should be built straight into git. The abstraction leaks are no worse than with submodules (it's just making different trade-offs) but the usability is so much more sane, it's not funny. The importance of having this in core-git can not be overstated. When it's not in core then it's not getting used. Case in point: count the number of projects on github using one of the external training wheels (subtree etc.). Submodules has proven inadequate for reality (again: count the number of subprojects on github). I wish one of the core-dev's would make a kickstarter for a solution...

exDM69 15y ago

> As it stands submodules don't even work sanely for the most trivial use-case of tracking a (slow changing) vendor-repo. That is not the use case it was designed for. And submodules still work just fine for that. The fact that you have to do a separate submodule update does not make it broken. In fact, it makes it better when you start thinking about all the corner cases there are. If you truly want to build a software out of subrepositories, you need to have a sane way of tracking working sets of revisions of all the submodules there are. And that is what git submodules does. If you were blindly tracking the head of a repository, it would be useful _only_ for the use case you mentioned. Tracking slowly changing external vendor repos. That would be a whole lot less useful.

moe 15y ago
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 even svn externals) and don't want to be exposed to all the corner cases and terrible usability.
- 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.