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

Hi Junio!

On Apr 8, 2008, at 11:43 PM, Junio C Hamano wrote:

"Avery Pennarun" [off-list ref] writes:

quoted

On Wed, Apr 9, 2008 at 12:39 AM, Roman Shaposhnik [off-list ref]  
wrote:

quoted

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.