Thread (4 messages) flat view 4 messages, 3 authors, 2016-06-15

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

From: Roman Shaposhnik <hidden>
Date: 2016-06-15 22:44:28

On Fri, 2008-04-11 at 00:07 +0800, Ping Yin wrote:
On Thu, Apr 10, 2008 at 11:43 AM, Roman Shaposhnik [off-list ref] wrote:
quoted
Hi Junio!
quoted
     * 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help