Subject: Re: Intricacies of submodules

From: Junio C Hamano <[email-masked]>
Date: Fri, 11 Apr 2008 22:11:52 -0700

Roman Shaposhnik <[email-masked]> writes:

> ... Contrast this with .gitconfig where policies get
> enforced right from the minute your clone operation finishes and there's
> much less opportunity for the user to shoot himself in the foot.

Why?  Even if you expect .git/config in a new repository would be vanilla
(which you can't really, as crazy sysadmin can have /etc/gitconfig or
template to override what you do), $HOME/.gitconfig would be in effect the
minute you clone.

As you cannot reasonably expect that your project is the _only_ project
your cloners would use, you cannot dictate what $HOME/.gitconfig has.

A policy issue needs to be addressed at the human level anyway, so I do
not really see major difference either way.  You need to trust your users
to follow the guideline at some point, and all you can do is to make it
easy for them to do so, and (optionally) verify that they are actually
following the guideline.  We need to suggest an easy-to-use and robust
mechanism to allow you to do so as the BCP.

Convenience and robustness need to be considered at the same time.  In
that area, I would say a custom "sane environment setup script" would be
the more flexible, as it rolls the customization and verification into one
step.

Trust goes mutual and your users need to be able to trust you, too.  If
the config mechanism blindly starts reading from in-tree .gitconfig, you
can do nasty things with aliases for example.  So the "sane environment
setup script" would also be a good idea in that sense, too --- the users,
perhaps only the most suspicious and untrusting kind, have a way to verify
it does not mean any harm before running it.

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).