On Thursday 2007, March 01, Brian Gernhardt wrote: > [attribute "image/png"] > path = *.png > show = "open %path%" > [attribute "text/plain"] > path = *.c > checkout = eol_to_local The problem is that this flips the relationship. What you want to do is assign attributes to paths. This is assigning paths to attributes. What about this: doc/*.txt = text/plain AND documentation In your system that would make [attribute text/plain] path = doc/*.txt show = "open %path%" [attribute documentation] path = doc/*.txt show = "open %path" i.e. you've got two sections to maintain instead of one. That's why I suggested: [attributes "doc/*.txt"] attributes = text/plain attributes = documentation I'm not really advocating that exact syntax, but I do think it's got to be like having a database like this: paths -> path-attribute-join <- attributes attributes -> handlers Your method does path -> attribute attribute -> handlers There would therefore be excessive repetition or impossible-to-specify connections. > Both of these lists look right at first glance, although I think I > prefer something simple like "show" to "prettyfilter". And we might > want a "reject" or "none" for merges... Attempting to merge a bitmap > is madness, so the system should just output a <file>- > <head>.<extension> or similar. I have no major concerns about any of the syntax really. The important thing is that we are clear and consistent (as always). > > + - Change of .gitattributes without change of files. > > + What happens when .gitattributes changes, but the files that > > would be > > + affected by that change do not? Those files really should be > > checked > > + out again, to apply any new outfilter settings. > > Actually, shouldn't the files also be run through the infilter to > check for changes caused by that, too? I don't think so. The effect of the infilter will never be seen in the working tree, because it's applied on git-add. The previous content with the old attributes are already in the repository. However, it could be that we would have to force those files to be marked dirty in the index (this is already sounding bad), to force the application of the infilter on next checkin. Perhaps that's what you meant, and I'm being slow. Andy -- Dr Andy Parkins, M Eng (hons), MIET andyparkins@xxxxxxxxx - 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