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

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Sep 26, 2011, 15:11 UTC
Message-ID: <4E809635.9050808@alum.mit.edu>
In-Reply-To: <20110926110552.GA20796@sigill.intra.peff.net>

On 09/26/2011 01:05 PM, Jeff King wrote:

Show 13 quoted lines

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

Show 11 quoted lines

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

Show 5 quoted lines

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