From: Junio C Hamano <hidden> Date: 2016-06-15 22:59:26
"W. Trevor King" [off-list ref] writes:
For
safety, maybe the default `init` should copy *everything* into
.git/config, after which users can remove stuff they'd like to
delegate to .gitmodules.
Copying everything into config is "be unsafe and inconvenient by
default for everybody", isn't it? Folks who want safety are forced
to inspect the resulting entries in their config file (which is more
inconvenent if you compare with the design where nothing is copied
and nothing dynamically defaults to what then-current .gitmodules
happens to contain). Folks who trust those who update .gitmodules
for them are forced to update their config every time upstream
decides to use different settings in .gitmodules, because they have
stale values in their config that mask what are in .gitmodules.
I think the solution we want is to copy only minimum to the config
(and that "minimum" may turn out to be "nothing"), and to default
keys that are only absolutely safe to .gitmodules file.
For
safety, maybe the default `init` should copy *everything* into
.git/config, after which users can remove stuff they'd like to
delegate to .gitmodules.
Copying everything into config is "be unsafe and inconvenient by
default for everybody", isn't it? Folks who want safety are forced
to inspect the resulting entries in their config file (which is more
inconvenent if you compare with the design where nothing is copied
and nothing dynamically defaults to what then-current .gitmodules
happens to contain). Folks who trust those who update .gitmodules
for them are forced to update their config every time upstream
decides to use different settings in .gitmodules, because they have
stale values in their config that mask what are in .gitmodules.
I think the solution we want is to copy only minimum to the config
(and that "minimum" may turn out to be "nothing"), and to default
keys that are only absolutely safe to .gitmodules file.
I agree and will prepare a patch for that.
What about teaching "git submodule sync" the "--url", "--update",
"--fetch", "--ignore", "--branch" and "--all" options to allow the
user to copy the current settings he wants from .gitmodules to
.git/config (but only safe values of course)? Trevor, would you be
ok to issue another command to copy everything to .git/config?
From: W. Trevor King <hidden> Date: 2016-06-15 22:59:26
On Thu, Dec 12, 2013 at 07:57:51PM +0100, Jens Lehmann wrote:
Am 12.12.2013 02:16, schrieb Junio C Hamano:
quoted
I think the solution we want is to copy only minimum to the config
(and that "minimum" may turn out to be "nothing"), and to default
keys that are only absolutely safe to .gitmodules file.
I agree and will prepare a patch for that.
What about teaching "git submodule sync" the "--url", "--update",
"--fetch", "--ignore", "--branch" and "--all" options to allow the
user to copy the current settings he wants from .gitmodules to
.git/config (but only safe values of course)? Trevor, would you be
ok to issue another command to copy everything to .git/config?
Sounds good to me. The more stuff I can leave in .gitmodules, the
happier I'll be ;). My second step will be removing “unsafe” values
from .git/config where possible, and I'll trust myself to check
.gitmodules after pulls.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:59:26
Jens Lehmann wrote:
Am 12.12.2013 02:16, schrieb Junio C Hamano:
quoted
I think the solution we want is to copy only minimum to the config
(and that "minimum" may turn out to be "nothing"), and to default
keys that are only absolutely safe to .gitmodules file.
I agree and will prepare a patch for that.
What about teaching "git submodule sync" the "--url", "--update",
"--fetch", "--ignore", "--branch" and "--all" options to allow the
user to copy the current settings he wants from .gitmodules to
.git/config (but only safe values of course)?
Why would I want to copy settings to .git/config when they are safe
enough to already be used directly from .gitmodules and the value from
.gitmodules is the one chosen to make sense when working with the
current revision?
URLs are kind of special because generally the newest value is the
most meaningful one, even when looking back over old history.
Thanks,
Jonathan