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. > Actually, even the simplest case of just cloning a repository with submodules > doesn't work: > After cloning, "git submodule status" shows "-", okay so I do "git submodule init", > which already shows a false understanding --- it shows the URL of the old repository, > from which the original submodule originated, which is long gone and no longer relevant. > Then of course "git submodule update" fails, and in the submodule there is just nothing. Then the URL of the submodule in the .gitmodules file is not up to date. You can either fix it there or - if you only want to change it locally - edit the .git/config after the "git submodule init" copied it there. > The problem seems to be that the information about the place where to update a > submodule is in .gitmodules, which git actually has under version control (different > from other configuration information), and thus copies it verbatimly. > Okay, then apparently after a clone .gitmodules has to be updated (by hand). No, the problem seems to be that the remote URL in the submodule has been changed directly without updating it in the .gitmodules of the superproject (the recommended way to do that is to change it in the .gitmodules file and then use "git submodule sync" to activate it). > So .gitmodules concerns only "git submodule update", not "git pull" from within > the submodules? This would be good to know, to understand the role of the information > in .gitmodules (where the task of "git submodule init" is apparently just to > transport this information to .git/configure ?). > > This has the disadvantage, that one has to publish this private > information about the places where by chance one is pulling from? Yes, the submodules URL must be available - at least for fetching - to everyone who wants to clone your superproject (and all changes made in the submodule which are committed in the superproject must have been pushed there to be able to check them out in the clone). > Perhaps I should then put .gitmodules into .gitignore? Or would that have > bad consequences?? Yes, because then git won't know where the it can clone the submodules from when you clone your superproject somewhere else. -- 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