On Tue, 10 Apr 2007, Josef Weidendorfer wrote: > > 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. > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html