Am 28.06.2011 12:05, schrieb Alexei Sholik: > On 27 June 2011 22:05, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> That is what I called "there is no direct way". Wouldn't it be nicer if >> the .gitmodules file in the superproject said something like >> >> [module "project one"] >> path = project1 >> url = ... >> depends = lib1 >> [module "lib1"] >> path = lib1 >> url = ... >> >> and then "git submodule init project1" run by the end user implied running >> also "git submodule init lib1"? > > This is a very nice idea. In my workflow, I find it that I more often > need to clone a repo _including_ its submodules, because the top-level > project won't compile without them. If we had a way to specify > dependencies on submodules, `git pull` could automatically init and > update them. While Junio's proposition was about initializing submodules that live next to each other you seem to be interested in recursive initialization. My plan is to add a flag to .gitmodules, say "autoinit", which will, when set, lead to a initialized and checked out submodule on clone. > If a user really wants to clone only the top-level repo without > submodules, git could provide him with an option for `git pull` (like > `git pull --shallow`) to do just that. I think this second scenario is > less common, so it is more reasonable to have a '--shallow' option for > it, instead of '--recursive' counterpart. Apart from the name, where I think "--recurse-submodules=none" is more consistent with the other options we have, this is the plan when clone learns to check out submodules too. -- 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