Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules

2013-12-12 Thread Junio C Hamano
Jens Lehmann writes: > Am 12.12.2013 02:16, schrieb Junio C Hamano: >> "W. Trevor King" 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

Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules

2013-12-12 Thread Jonathan Nieder
Jens Lehmann wrote: > Am 12.12.2013 02:16, schrieb Junio C Hamano: >> 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 pa

Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules

2013-12-12 Thread W. Trevor King
On Thu, Dec 12, 2013 at 07:57:51PM +0100, Jens Lehmann wrote: > Am 12.12.2013 02:16, schrieb Junio C Hamano: > > 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 .gitmod

Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules

2013-12-12 Thread Jens Lehmann
Am 12.12.2013 02:16, schrieb Junio C Hamano: > "W. Trevor King" 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 in

Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules

2013-12-11 Thread Junio C Hamano
"W. Trevor King" 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 wh

Re: [git] Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules

2013-12-11 Thread W. Trevor King
On Wed, Dec 11, 2013 at 11:26:17PM +0100, Jens Lehmann wrote: > Am 10.12.2013 00:40, schrieb Junio C Hamano: > > Heiko Voigt writes: > >> This notion has changed in a way that only the url (by that the > >> name) should be copied on init. The default for everything else > >> should come from .gitm

Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules

2013-12-11 Thread Jens Lehmann
Am 10.12.2013 00:40, schrieb Junio C Hamano: > Heiko Voigt writes: > >> This notion has changed in a way that only the url (by that the name) >> should be copied on init. The default for everything else should come >> from .gitmodules or gits own default. > > I think you need to be a bit careful

Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules

2013-12-09 Thread Junio C Hamano
Heiko Voigt writes: > This notion has changed in a way that only the url (by that the name) > should be copied on init. The default for everything else should come > from .gitmodules or gits own default. I think you need to be a bit careful here. I do not think everything should blindly default

Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules

2013-12-09 Thread Heiko Voigt
On Fri, Dec 06, 2013 at 03:48:46PM +, Charlie Dyson wrote: > gitmodules(5) states that submodule.$name.update should be defined in > .gitmodules. However in cmd_update() in git-submodule.sh, git config > is used with "-f .gitmodules". Consequently this flag is only > respected in .git/config >

git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules

2013-12-06 Thread Charlie Dyson
gitmodules(5) states that submodule.$name.update should be defined in .gitmodules. However in cmd_update() in git-submodule.sh, git config is used with "-f .gitmodules". Consequently this flag is only respected in .git/config Tested against: 1.8.2.1 [sorry! I've checked the relevant bit of source