On Fri, 2008-04-11 at 22:11 -0700, Junio C Hamano wrote: > Roman Shaposhnik <rvs@xxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
