% cd subpath
% git submodule add <remote> <into/the/project>
> a major step down from Subversion, where the subtree
> repository support
Repo was made prior to Git submodules to do the exact same thing for Android. Now that Git has submodule support, Repo is useless. It does pretty much the same thing as submodules, but it does it in a very crappy way.
For example, you cannot go back to a specific set of versions of subdirectories with Repo. In other words there's no "global" git bisect as there would be with submodules. This stops you from automatically finding a problem in one of the submodule repos if there are dependencies betweeen the problematic repo and other repositories.
"...the reason we made repo was because we didn't want to deal with commits in the super project, or trying to merge concurrent branches in the super project. Instead we wanted each subproject to use a floating branch as the revision it is tracking."
Another decision the Repo designers made that I disagree with is the silly Change-Id added to every commit message(!). Since when do globally unique identifiers (GUIDs) solve problems instead of creating more?
Also, if you do use Gerrit (even though you don't seem to like it) it has some better support for submodules from 2.3 onwards. See https://gerrit-review.googlesource.com/Documentation/user-su...
One of the best benefits I see is that submodules make embedding forks more manageble. For example, when you include an open source library in your own project, it's common that you'd want to modify the library in some way. If you commit the modified library into your own project's repository, you'll have a harder time absorbing bug fixes/features from upstream later on. Instead of a simple merge, you'd have to check out the updated library somewhere else and use a diff tool to compare the changes. And, if the library changed much, you may need to find the specific commit that your modification were based off so you can understand how to rebase your modifications.
In addition, submodules makes it easier to: contribute bug fixes/patches, share modified open source library across different projects, and identify bugs introduced in updated submodules (since the history is preserved).
Also, if repository A and B reference repository C as a submodule and I update repository C for A, B would not be affected since submodule references are just commit IDs. There's no need to create two additional mirrors (C-for-A and C-for-B) if that's what you meant.
Even if you think you're perfect and never make mistakes, it's not a good idea to add easy opportunities to make mistakes.
This is excellent news. I've been using git subtree for a couple of years now without incident, and highly recommend it.
having worked with all-in-one repos, where external stuff is thown in... then rots... submodules are a better way, making keeping external code up to date. simple yet controlled.
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.
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.
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.
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.
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...
However, most likely you don't want an automatic submodule update because of all the issues there are. It would only be useful for tracking a very stable slow moving external dependency.
The key to submodules is that you should not update them on a regular basis. A good example is the Gitflow project that uses the shFlags repo as a submodule.
A small gotcha is that you need to use --recursive when cloning the repo, so that you get the submodule cloned as well.
I need to have a consistent set of all the submodules I'm working with. I need to reliably get the exact same versions of all the modules in the big repository. This allows me to do a "git bisect" to search for problems in submodules.
Doing "git submodule update" is not as bad as the OP suggests it is. It makes perfect sense to have it as it is.
Did you notice I specifically said "my situations"? I wasn't talking about your situations, and it appears that the existing mechanism suits your needs. It does not suit mine and has been so problematic that I had to abandon use of submodules.