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

[Michael Haggerty <mhagger@alum.mit.edu>]

On 09/26/2011 01:05 PM, Jeff King wrote:
> On Sat, Sep 24, 2011 at 01:03:50PM +0200, Michael Haggerty wrote:
>> 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.

I hadn't realized this point about the split between gitconfig and
gitattributes.  It makes sense.  I'd been thinking that it would be nice
to be able to share changes to the git config the same way that source
code is shared, but you are right that the git config is versioned
differently than the source code.  I can't think of any counterexamples
right now.

>> 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.

This is more a reason to implement a way to "unset" options than an
argument against storing git's builtin defaults in a gitconfig-formatted
file.

> 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?

I think that git should read its "as-installed" config file at runtime
to maximize the transparency.  If the file is missing then git should
fail, just as it would if some other important part of git were missing
from an install.  The absence of a required config option would be a bug
and might cause git to abort just like any other bug.

I probably shouldn't mention this lest people realize that I'm stupid
and ugly, but...

Subversion installs a file with all of its defaults into your
~/.subversion directory the first time that it runs.  I find this
feature to be very helpful as a source of examples and to learn new
features.  But they do it a bit differently than I am proposing for
git--the file is written to the user's ~/.subversion, and is
subsequently edited by the user.  Because the file lives across
Subversion upgrades, the options in this file are *commented out* to
prevent them causing trouble in the future; i.e., they are for human
consumption only.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/