On 03/10/2015 09:26 PM, Torsten Bögershausen wrote: > On 10.03.15 20:25, Michael Haggerty wrote: >> [...] >> I'm still trying to infer the spirit of the current behavior, so caveats >> here. >> >> This comes from a real-life scenario where a user, somewhere early in >> .gitattributes, had >> >> * text >> * eol=crlf >> >> and then later (this could be in a subdirectory) tried to carve out >> exceptions to this rule by using >> >> *.png binary >> * text=auto > Hm, > I can see 2 problems here: > the "binary" attribute does not exist at all. > > I sometimes which we had it, but we don't. > There is "text" and "-text", and that is it. There is a "binary" macro that is equivalent to "-diff -merge -text". It is documented in gitattributes(5) under "USING MACRO ATTRIBUTES" and "DEFINING MACRO ATTRIBUTES". > The other problem is the order of the lines, which is fully > intuitive for each person who has ever written a "matching parser". > > The parser matches each file namr on it's own, depending on the matching: > > *.png -text > * text=auto > means that all png files are binary, and ALL files are "auto". > > Guess what happens to the png's ? > > The second rule wins, as it is the last rule processed. > > git check-attr text * > A.png: text: auto > B.txt: text: auto That much is perfectly clear. The question is, what should happen when the contents-based heuristic, whose use was requested by "text=auto", determines that A.png is in fact a binary file? Should it be subjected to EOL translation anyway? I think not. Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx -- 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