Intricacies of submodules [was: Migrating svn to git with heavy use of externals]

From: Roman Shaposhnik <rvs@sun.com>
Date: Apr 10, 2008, 03:43 UTC
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:

Show 14 quoted lines

> "Avery Pennarun" <apenwarr@gmail.com> writes:
>
>> On Wed, Apr 9, 2008 at 12:39 AM, Roman Shaposhnik <rvs@sun.com>  
>> 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.

Show 10 quoted lines

> 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.

Show 9 quoted lines

> 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.