On Monday 21 May 2007, Sven Verdoolaege wrote:
> 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
-
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
