Re: [PATCH] Quick description of possible gitattributes system

[Brian Gernhardt <benji@silverinsanity.com>]

On Mar 2, 2007, at 2:35 PM, Andy Parkins wrote:

>> .git/config:
>> [attribute "image"]
>>     show = ...
>>     merge = ...
>>
>> With the ability to have additional "path =" entries for *local*
>> overrides/additions.  Storing the handler information in
>
> That's almost exactly it; but it makes the assumption that each
> attribute will have one unique handler.  Separating them means that
> multiple attributes can use one handler (or set of handlers).

That's why I suggested keeping the handler section, but not tying  
handlers to attributes in the attribute section.  I think it follows  
the principle of least surprise to be able to do as I demonstrated  
above, but allow reuse as I described originally (handler option in  
the attribute section).  My major concern is how do you tell what  
order handlers are run in for a given file if the handlers specify  
the attributes rather than the other way around?  And why make the  
user do things like:

[handler "text"]
    attribute=text
    ...

Instead of:

[attribute "text"]
    ...

(The handler section could be called "mangle", "blah", or "why-do-I- 
have-to-name-this", and the point would be the same.)  If you want to  
run the same handlers/filters/whatever for multiple types, create a  
handler section and reference it from all of those types or give all  
the files a new attribute that explains why you'd want to handle them  
identically and put the options on that attribute instead.

The attribute is the important thing here, not the handlers, so they  
should be primary, not secondary.  And that's my major point that I'm  
trying to get around to I guess.  I don't care about naming handler  
sections, searching through the file to find their order, or anything  
other than *what git is doing to my files*.  The files (content,  
actually) are king.

~~ Brian