Re: [RFC] Third round of support for cloning submodules

From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: May 21, 2007, 10:44 UTC
Message-ID: <200705211244.16374.Josef.Weidendorfer@gmx.de>
In-Reply-To: <20070521095749.GI942MdfPADPa@greensroom.kotnet.org>

On Monday 21 May 2007, Sven Verdoolaege wrote:

Show 13 quoted lines

> On Mon, May 21, 2007 at 12:26:21AM +0200, Alex Riesen wrote:
> > Sven Verdoolaege, Sun, May 20, 2007 23:47:32 +0200:
> > > 
> > > How would _you_ specify which subprojects to checkout ?
> > > 
> > 
> > Aren't the ones which already have .git in them are kind of specified?
> > 
> 
> Would you always recurse into these submodules, regardless of
> any option?
> Or would you want two options, one for handling the submodules
> you have explicitly marked someway and one for getting all submodules?

There should be a way for a superproject to specify useful sets of subprojects for different developer roles, and these sets should be versioned. It is also useful for a superproject to be able to say "for this subproject to work, that other subprojects needs to be checked out".

Both issues could be supported with a "dependson" setting in .gitmodules (or better call this file ".gitprojects"?)

 [subproject "german-translation"]
    path = lang/german
    dependson = docbuilds

 [subproject "all-translations"]
    dependson = german-translation france-translation japanese-translation

The syntax here only is RFC, including the fact that this example puts the subproject identifier into the key, and the path as config. If we do not go the .gitattributes way, IMHO this is more logical.

When cloning, one should be allowed to specify the subprojects one wants to track, e.g.

 git-clone --subproject=all-translations ...

Josef