Subject: Re: Intricacies of submodules

From: Roman Shaposhnik <[email-masked]>
Date: Mon, 14 Apr 2008 12:52:20 -0700

On Fri, 2008-04-11 at 22:11 -0700, Junio C Hamano wrote:
> 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.

I think I understand where you are going with this. Although, truth be
told, to me ~/.gitconfig is much less of a concern. Why? Well, because
by definition if the user is smart enough to edit ~/.gitconfig I'm
not concerned about him. As I pointed out my main concern is about
junior developers for whom the only way to screw things up would
be to have a global /etc/gitconfig, which is still quite rare.

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

See, that's exactly why I would love to have in-tree .gitconfig ;-) 
~/.gitconfig is not flexible enough to have settings for multiple
projects and .git/config needs to be managed by scritps. In-tree
.gitconfig just works.

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

And that's where it becomes a matter of preference. I can now see your 
point very clearly and I tend to slightly disagree with it. But! This
is definitely not a technical issue anymore (in-tree .gitconfig and
in-tree shell script for managing .git/config are technically 
equivalent). So, I think I don't have any more arguments to add to the
discussion. I do have one question left (see bellow) and one comment 
to make: my experience has been that it is much easier to trust
volunteer and open source developers compared to corporate ones. 
I do get it 100% that Git is "for the kernel folks; by the kernel folks"
and I actually think that it is a healthy environment for an SCM to
grow in. But!

All I'm saying is that if the needs of the corporate folks can be taken
into account without doing Git's architecture any harm I think they
should be.

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

Thanks,
Roman.