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

From: Roman Shaposhnik <[email-masked]>
Date: Thu, 10 Apr 2008 12:27:33 -0700

On Fri, 2008-04-11 at 00:07 +0800, Ping Yin wrote:
> On Thu, Apr 10, 2008 at 11:43 AM, Roman Shaposhnik <[email-masked]> wrote:
> > Hi Junio!
> >
> 
> >      * 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.
> >
> 
> I like this idea, it's another common/special requirement just like
> .gitignore vs. $GIT_DIR/info/exclude.

Well, I guess if enough of us like it there's a chance it can be
implemented, right? ;-)

To some extent it seems that you've solved this particular issue for 
submodules with your PATCH/RFC 3/7. Now, in a general case, if 
git-config(1) can be patched to take into account one extra place
for retrieving options from (.gitconfig) it seems that
retiring .gitmodules completely would be just one benefit of many.
Other benefits would include propagating setting like most of the
core.* and quite a few other things I see listed in git-config(1)
man page.

It seems that the only downside here would be a need for a bit
of special handling when a setting needs to be recorded. Otherwise
it looks like a pretty clean and general idea.

Thanks,
Roman.