Am 02.01.2011 16:55, schrieb Oliver Kullmann: > On Sun, Jan 02, 2011 at 12:30:15PM +0100, Jens Lehmann wrote: >> Am 01.01.2011 21:39, schrieb Oliver Kullmann: >>> On Fri, Dec 31, 2010 at 06:42:01PM -0500, Seth Robertson wrote: >>> As far as I see that, this doesn't concern the problem how to I update >>> one repository with submodules from another repository with "these" submodules >>> (as the same paths)? >> >> I'm not sure I completely understand your use case, but submodules are >> repositories of their own, so they don't get updated by just pulling >> a superproject into another containing the same submodule. The submodule >> changes have to be pushed to its own parent repository and can then be >> fetched from there into another superproject's submodule. > > I know that --- but if there wouldn't be any savings possible (in terms of using it), > then submodules would be pointless, and so the question is *how* to use them. No, they aren't pointless at all. But if you want to collaborate using submodules they IMO work best if all your coworkers are able to access the same submodule repos you are pushing to. Otherwise you'll have to transport all submodule changes additionally to those of the superproject (which might be more of a hassle than not using submodules in the first place). Then you might be better off pulling the modules into your repo using "git subtree" or "gitslave". A possibility to put all submodule commits in the object directory of the superproject has been discussed some time ago on this list [1] and at the last GitTogether. That might be just what you need, but I am not aware of any work done in that direction yet. > The good thing with Git is that there are no central repositories. > That's exactly what I want to use, but again and again the automatic > assumptions of "central repositories" are made, which should be actually alien to Git. No, Git works perfectly fine with central repositories too (and that is a feature :-). But I think I understand where your impression comes from. Submodules don't work very well when you change URLs (that can result in forcing your coworkers to do a "git submodule sync" in their repo every time they switch to a commit with a changed URL). But while that somehow works not being able to access a submodules repo doesn't work at all. So the constraint for submodules is to have a repo which is visible for the people you work with. But submodules don't really force you into the centralized model, as you can modify the .gitmodules file e.g. in a downstream fork and let it point to your own forked version of the submodules repos where you can do your own development independent of the submodules upstream. > Puuuh, I really really tried hard now to make my use-case clear :-|. Hopefully > now the picture emerges. Yep, thanks for sharing that! [1] http://thread.gmane.org/gmane.comp.version-control.git/151473/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html