Re: How to use git attributes to configure server-side checks?

[Jeff King <peff@peff.net>]

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