Re: tracking submodules out of main directory.

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 28.06.2011 12:05, schrieb Alexei Sholik:
> On 27 June 2011 22:05, Junio C Hamano <gitster@pobox.com> 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.