Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules
Jens Lehmann <Jens.Lehmann@web.de> writes:
Show 28 quoted lines
> Am 12.12.2013 02:16, schrieb Junio C Hamano:
>> "W. Trevor King" <wking@tremily.us> 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.
>
> 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)?
An option per variable, which forms an unbounded set over time? From the syntax point of view, "--copy-config=url,update,..." probably is a better option, but I think that misses the point. Copying will freeze the choice in stone.
Also, as long as the copying is deliberately done with such an option, copying potentially "unsafe" ones is perfectly fine.
Reading and using what are not copied from the .gitmodules file _is_ a lot more severe security risk, so your "only safe ones, of course" should apply more heavily on that side. In principle, by default, we should use *nothing* from .gitmodules, and make exceptions on case by case basis, allowing only the safe ones.
What is missing is a support for those like W. Trevor who trust what are in .gitmodules, and want to use values from there for ones we do not add to that default list of exceptions. They are not helped by such an option to say "copy these keys from .gitmodules to my config". They do not want to freeze values to what was in there at one point. They want to just follow along, whatever values happen to be set in the .gitmodules file of the day.
So I _think_ a better approach would be to let users say something like:
[submodule "frotz"]
useInTreeSetting = update ignorein their .git/config file in the repository of the top-level project, to tell Git:
When 'submodule.frotz.update' or 'submodule.frotz.ignore' is
needed, please read from the .gitmodules file to grab the value
for that setting. I trust the project as a whole to set a
suitable value for me.and copy almost nothing to .git/config file upon 'init' time.
If we were to go this route, I would envision that this new variable would be a list of keys to additionally allow defaulting to the values found in .gitmodules; if we hardcode 'branch', for example, as one of the keys that we fallback to .gitmodules, and if the user does *not* want to follow along to the project's recommendation, the user can just set "submodule.frotz.branch = <desired value>" in the .git/config file, and there is no need for the useIntreeSetting variable to support "Git by default may allow this variable 'branch' to be read from .gitmodules but I do not like that".
