On Tue, 10 Apr 2007, Josef Weidendorfer wrote:
quoted text
> 
> So when moving the kdelibs submodule around, you would
> have to update the .gitmodules file.

Right. The assumption here is:
 - submodules almost never actually change. You might add a new one 
   occasionally, and once a decade you might do some bigger 
   re-organization, but in general it's pretty much static.
 - when you do move submodules around, it's probably a big flag-day anyway 
   (ie I would expect that it's a big reorg, and that you'd quite likely 
   expect developers to have to re-check out their tree if you did major 
   surgery).

That's certainly how it works under CVS. I bet we can make it much nicer 
than CVS, but the point is, people really don't expect submodules to be 
something that you move around very dynamically. You want to be *able* to 
move them around, but it's not a normal operation.

quoted text
> I like it.

The advantage with splitting things out like this is that it allows you 
much more flexibility than something automatic and deeply integrated does. 

You can still edit the modules setup even if you yourself might not even 
have that particular module checked out! That may sound insane, but it's 
actually *required* for things like "oh, the standard server for that 
module went away, I need to edit the module settings to get it from xyz 
instead".

		Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html