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

On Sat, Sep 24, 2011 at 01:03:50PM +0200, Michael Haggerty wrote:

quoted

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