Roman Shaposhnik <rvs@xxxxxxx> 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. -- 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
