Thread (23 messages) flat view 23 messages, 6 authors, 2016-06-15

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

From: Josef Weidendorfer <hidden>
Date: 2016-06-15 22:43:11

On Monday 21 May 2007, Sven Verdoolaege wrote:
On Mon, May 21, 2007 at 12:26:21AM +0200, Alex Riesen wrote:
quoted
Sven Verdoolaege, Sun, May 20, 2007 23:47:32 +0200:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help