Re: Intricacies of submodules

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 12, 2008, 05:11 UTC
Message-ID: <7vlk3jlkrr.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <1207970038.10408.8.camel@ginkgo>

Roman Shaposhnik <rvs@sun.com> 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).