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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html