Re: Intricacies of submodules

[Junio C Hamano <gitster@pobox.com>]

Roman Shaposhnik <rvs@sun.com> writes:

>> Don't get me wrong.  I am not saying that everybody should start rolling
>> their own "sane environment setup script" and ship their project with it.
>> I am only suggesting it as a possible way to do your "policy enforcement"
>> without having to introduce in-tree .gitconfig, which I unfortunately see
>> no fundamental upsides but definite downsides (security included).
>
> And here comes my question: could you, please, elaborate on *technical*
> drawbacks of in-tree .gitconfig (such as security that you've
> mentioned).

Just to name a few, as I do not see a point in spending time elaborating
in detail when there is an alternative without such security downsides.

One of your examples was about a forced use of custom merge tool.
Consider in-tree .gitconfig that is always read for everybody that
describes such a tool.  A malicious script named there is a security risk
for people who clone such a project.  A smudge filter is even worse, as it
kicks in the minute you try to check out the project.

These executable (not just merge tool or attribute filters) are designed
to be named by .git/config exactly because .git/config is designed to be
personal (i.e. "that _particular repository only_") and you can afford to
be environment and platform specific there.  If you start describing them
in in-tree .gitconfig, they must be cross platform and (worse yet)
you have to make sure they are installed everywhere.

There are states recorded by git-submodule whether the particular
repository has seen and is interested in which submodule (i.e. "submodule
init" has been run).

I'm too lazy to make a laundary list of what you can have in .git/config
with the current system (see Documentation/config.txt), but that part of
the system is built around the design that the configuration is specific
to the repository (and sharing what the user records in ~/.gitconfig
across repositories is in line with it).

Unless you are willing to sift through all of them, mark which ones can be
overriden by in-tree .gitconfig and which ones cannot, and implement an
easy to use (by both the developers and the users) mechanism to enforce
the distinction, just changing the git_config() function to read from one
new place (i.e. in-tree .gitconfig) would not be a sufficient solution for
what you seem to want to do.