Re: Intricacies of submodules [was: Migrating svn to git with heavy use of externals]
- From
- Roman Shaposhnik <rvs@sun.com>
- Date
- Apr 10, 2008, 19:27 UTC
- Message-ID
- <1207855653.13123.257.camel@work.sfbay.sun.com>
- In-Reply-To
- <46dff0320804100907w5240b79bga3acad9fb8ecb353@mail.gmail.com>
On Fri, 2008-04-11 at 00:07 +0800, Ping Yin wrote:
Show 16 quoted lines
> On Thu, Apr 10, 2008 at 11:43 AM, Roman Shaposhnik <rvs@sun.com> 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.