On Sat, Sep 24, 2011 at 01:03:50PM +0200, Michael Haggerty wrote: > > But once you've verified that the config looks OK and turned this option > > on, how do you protect yourself from malicious config entering the repo > > through a fetch? > > For most software projects, the user does > > git pull > make > > daily. There is nothing that a nasty .gitconfig can do that can't be > done more easily by a nasty Makefile (or anything else in the build > process). The moment I pull from Junio's repository and run a build > without having personally done a full code review first, I've given > Junio complete pownership of my account. For projects in which I invest > such trust, "core.useTreeConfig=true" would be a convenience that does > not appreciably increase my risk. True. I think it would be nice for their to be a less risky option, too, though. Which was part of the motivation in my earlier proposal for specifying a ref that contains config. Then you can ignore it, track your own local config which is derived from upstream, or do the easy but dangerous thing of just using the remote tracking ref directly. > There are obviously config options that should not be versioned. These > should not be stored in the tree. (Perhaps they should be stored in > another branch, as you suggested.) But there's no need to prevent > people from versioning *any* config options just because they shouldn't > version *all* of them. Do you have an example of a config option whose old value should be respected when looking at an old version? In general, the split between attributes and config was meant to split what is tied to a specific version, and what should apply to all versions. We may not have followed that in all cases, but if so, the right solution may actually be migrating the functionality into .gitattributes. > While we are on the topic of config settings, I have often thought that > it would be nice for git's default settings to be set via a > well-commented config file, installed along with git, rather than via > values compiled into the code. This file and Documentation/config.txt > could be generated from a single source file as part of the build > process. I think that can be a nice piece of documentation, but there may be some complications. I seem to recall that there may be one or two options whose builtin values cannot be replicated via config (i.e., the "unset" state means something). But I may be misremembering. However, I'm not sure what you mean by "rather than via values compiled into the code". Would you somehow generate code that sets the default according to your master file? Would git fail to start if the file is missing? Or if a specific config option is missing? How would you track that? -Peff -- 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