On Fri, Dec 31, 2010 at 06:42:01PM -0500, Seth Robertson wrote: > > In message <20101231222438.GA28199@xxxxxxxxxxxxxxxxxxxxx>, Oliver Kullmann writ > es: > > it would be very helpful if somebody could tell me the > supposed workflow how to update a submodule (I'm using version > 1.7.3.2; the man-page doesn't say much about it). > > https://git.wiki.kernel.org/index.php/GitSubmoduleTutorial > thanks, that's definitely something. > -------------------------------------------------- > cd submodule_path > git checkout <branchname> > git pull > cd .. # or otherwise get to the superproject > > git add submodule_path > git commit -m "Updated submodule to latest <branchname>" > git submodule update > -------------------------------------------------- > > This (untested) code obviously only works for a single repository. If > you want to do it for all repositories, you need something more like > the untested: > > -------------------------------------------------- > git submodule foreach git checkout <branchname> > git submodule foreach git pull > git add -a -m "Updated all submodules to latest <branchname>" > git submodule update > -------------------------------------------------- > 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)? 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. A clone should provide a relation to the mother-clone, not transitively to the grandmother-clone. 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). 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? Perhaps I should then put .gitmodules into .gitignore? Or would that have bad consequences?? Or is the idea that .gitmodules normally is not under version control, and thus "git init", which actually hides the information of .gitmodules ? > If you find yourself doing this continuously, and doing it for all of > your submodules, you may way to use gitslave instead of submodules > which keeps the branches checked out all of the time so all you need to > do is `git pull`. This may be better, or worse, for you workflow. > > gitslave (http://gitslave.sf.net) is useful when you control and > develop on the subprojects at more of less the same time as the > superproject, and furthermore when you typically want to tag, branch, > push, pull, etc all repositories at the same time. > On the one hand, I always want to pull "everything" (inclusive the content of all submodules), however the submodules are completely independent (they are from Github, or collaborations on papers, and such things --- I just want to conveniently carry around all of that with me in one go). > git-submodule is better when you do not control the subprojects or > more specifically wish to fix the subproject at a specific revision > even as the subproject changes > This seems to be the case here, so it seemed to me that gitslave wouldn't be appropriate here. Thanks for your help! Oliver -- 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