Re: [PATCH] Quick description of possible gitattributes system

From: Brian Gernhardt <benji@silverinsanity.com>
Date: Mar 2, 2007, 20:35 UTC
Message-ID: <8CAB85E5-A98E-4A25-9CC2-3E59106E655C@silverinsanity.com>
In-Reply-To: <200703021935.58992.andyparkins@gmail.com>

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

Show 11 quoted lines

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