From: Roman Shaposhnik Date: Thu, 10 Apr 2008 03:43:34 GMT Subject: Intricacies of submodules [was: Migrating svn to git with heavy use of externals] Message-ID: <6CFA8EC2-FEE0-4746-A4F6-45082734FEEC@sun.com> In-Reply-To: <7vhcebcyty.fsf@gitster.siamese.dyndns.org> Hi Junio! On Apr 8, 2008, at 11:43 PM, Junio C Hamano wrote: > "Avery Pennarun" writes: > >> On Wed, Apr 9, 2008 at 12:39 AM, Roman Shaposhnik >> 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. Got it. But if you don't mind, I still would like to ask you a few questions to clarify some things. > 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. Ok. Now I understand that .git/config is supposed to be the authoritative source of information on submodules. Yet we also have .gitmodules to take care of. This leads to information duplication and makes me believe that .git/config should be as much as sync with .gitmodules as possible. Yet, even with the latest version of Git we don't have "git submodule add" updating .git/config. So here comes the first question: * Do you consider this behavior to be a bug or do you a have a reasonable explanation for it? Continuing in the same line of though as far as information duplication goes, here's my second question: * Whenever .gitmodules and .git/config disagree on the URL for a particular submodule do you expect .git/config to always take precedence? And finally, since from your explanation it appears that the only reason for .gitmodules existence is to "prime" the .git/config it seems that what we're trying to achieve is a way for Git settings that are usually part of .git/config to be resident within the repository itself. That would give these setting a benefit of percolating through clone/fetch/push operations, yet be overridden by individual .git/config settings. And so I have my final question: * Has an idea of having a regular file (subject to having history, etc.) called something like .gitconfig at the top level of Git's repository ever been considered (implemented?). That way you a repository maintainer would be able to force a particular set of settings on all of its clones yet clones will be able to override then in .git/config if needed. > 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. Indeed. This is a very beneficial setup for large projects. In fact, what I'm working on right now is a prototype of a build infrastructure that would be smart enough to import "cached" binaries of the build of a particular submodule if the submodule itself hasn't been checked out yet. SHA1 lets me do the versioning properly and once developers do checkout sources of any submodule the build system will stop importing "cached" binaries and start build it for real. All without developers actually doing anything special. Thanks, Roman.