Jon Loeliger [off-list ref] writes:
So, like, Junio C Hamano said:
quoted
Stefan Beller [off-list ref] writes:
quoted
Do we want to invent a special value for url.*.insteadOf to mean
"look up in superproject, so I don't have to keep
a copy that may get stale" ?
My gut feeling is that we should do the selective/filtered include
Peff mentioned when a repository is known to be used as a submodule
of somebody else.
Does the management of these submodue-related config values
become easier if, instead of placing them in .config, we
place them in a git/.context file?
Do you mean that Git users that use submodules adopt a convention
where a separate file in $GIT_DIR of the toplevel superproject holds
pieces of configuration that are meant to be shared between the
superproject and across all its submodules, and the $GIT_DIR/config
file in submodules and the superproject all include that shared one
via include.path mechanism?
That may allow us to do without being responsible for sifting of
configuration variables into safe and unsafe bins.
I dunno.
On Wed, Feb 22, 2017 at 09:36:12AM -0800, Junio C Hamano wrote:
quoted
quoted
My gut feeling is that we should do the selective/filtered include
Peff mentioned when a repository is known to be used as a submodule
of somebody else.
Does the management of these submodue-related config values
become easier if, instead of placing them in .config, we
place them in a git/.context file?
Do you mean that Git users that use submodules adopt a convention
where a separate file in $GIT_DIR of the toplevel superproject holds
pieces of configuration that are meant to be shared between the
superproject and across all its submodules, and the $GIT_DIR/config
file in submodules and the superproject all include that shared one
via include.path mechanism?
That may allow us to do without being responsible for sifting of
configuration variables into safe and unsafe bins.
I dunno.
Hmm. I certainly like that we punt on having to decide on the "should
this be shared with submodules" decision. That makes the end result more
flexible, and we don't have to get into a never-ending stream of
"whitelist this config option" patches.
My only concern is that it's not as discoverable. In the situation that
kicked off this thread, somebody put url.X.insteadOf into their
super-project .git/config, expecting it to work in the submodules. That
_still_ wouldn't work with this proposal. They'd have to:
1. Put it in .git/context (or whatever we call it)
2. Maybe add include.path=context in .git/config if they want the
config shared with the super-project (or this could be automatic?)
I guess it gives _a_ solution, which is more than we have now, but it
doesn't feel very ergonomic.
-Peff
On Wed, Feb 22, 2017 at 10:57 AM, Jeff King [off-list ref] wrote:
On Wed, Feb 22, 2017 at 09:36:12AM -0800, Junio C Hamano wrote:
quoted
quoted
quoted
My gut feeling is that we should do the selective/filtered include
Peff mentioned when a repository is known to be used as a submodule
of somebody else.
Does the management of these submodue-related config values
become easier if, instead of placing them in .config, we
place them in a git/.context file?
Do you mean that Git users that use submodules adopt a convention
where a separate file in $GIT_DIR of the toplevel superproject holds
pieces of configuration that are meant to be shared between the
superproject and across all its submodules, and the $GIT_DIR/config
file in submodules and the superproject all include that shared one
via include.path mechanism?
That may allow us to do without being responsible for sifting of
configuration variables into safe and unsafe bins.
I dunno.
Hmm. I certainly like that we punt on having to decide on the "should
this be shared with submodules" decision. That makes the end result more
flexible, and we don't have to get into a never-ending stream of
"whitelist this config option" patches.
My only concern is that it's not as discoverable. In the situation that
kicked off this thread, somebody put url.X.insteadOf into their
super-project .git/config, expecting it to work in the submodules. That
_still_ wouldn't work with this proposal. They'd have to:
1. Put it in .git/context (or whatever we call it)
2. Maybe add include.path=context in .git/config if they want the
config shared with the super-project (or this could be automatic?)
I guess it gives _a_ solution, which is more than we have now, but it
doesn't feel very ergonomic.
Well, currently ".git/config" is the one and only blessed way to configure
a single repo and our documentation and user expectations reflect that.
Once git-worktree takes off (which has per working tree configuration files)
it doesn't feel as obscure anymore to have multiple config files.
The working trees will share the $GIT_COMMON_DIR/config file for
all working trees and have its own config file at $GIT_DIR/config.worktree
in its respective git directories. C.f.
https://public-inbox.org/git/20170110112524.12870-2-pclouds@gmail.com/
So I could imagine that we just introduce another config file
config.submodules which is source'd by the submodules.
Then the hard part becomes to decide which config value to put
in which config file. (We'd still be left to guess where to put some initial
new configuration value. config or config.submodules. Any update of a
value can just stay in its respective file. And I don't think we'd want
to invent a config option that tells us which policy we use where to
put config options. That sounds just scary.)