"Avery Pennarun" <apenwarr@xxxxxxxxx> writes: > On Wed, Apr 9, 2008 at 12:39 AM, Roman Shaposhnik <rvs@xxxxxxx> wrote: >> Agreed. But I guess I'd be less confused if "git submodule" didn't muck >> with .git/config at all. Or are there any other consumers of the >> information >> that it puts there (except itself)? > > That I don't know. If there aren't any others, then I agree, I'm not > sure what the whole .git/config messing is about. Its actually the other way around. In-tree .gitmodules is used to give hints to prime what is placed in .git/config, which after initialized should serve as the authoritative information on managed submodules as far as your repository is concerned. "git submodule init" may be a handy way to do this "priming", but you do not necessarily have to use it but instead manually adjust .git/config yourself; this is so that you can configure remote url that is different from what .gitmodules suggests to suite your local needs. Although putting everything in a single repository could work, that does not have to be the only way to work with submodules. In fact, the basic submodule design is trying very hard not to force you to grab objects that are needed for all submodules when you are cloning the superproject, as not cloning nor checking out any submodule is the default. -- 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
