On 10.03.15 20:25, Michael Haggerty wrote: > On 03/06/2015 10:30 PM, Torsten Bögershausen wrote: >> >>> Oops, I misunderstood an internal bug report. In seems that it is the >>> following scenario that is incorrect: >>> >>> *.png text=auto eol=crlf >> Hm, I don't know if we support this combination at all. > > The user can specify this combination in a .gitattributes file and we > have to react to it *some way*. Theoretically we could document that > this combination is undefined and/or emit an error if we see this > combination, but we don't do so. > >> The current logic supports auto-detection of text/binary, >> * text=auto >> (the files will get the line ending from core.eol or core.autocrlf) >> >> or the the setting of a line ending: >> *.sh eol=lf >> *.bat eol=crlf >> >> >> Is there a special use-case, which needs the combination of both ? > > 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. 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 --- If we reverse the order in .gitattributes, things look better: * text=auto *.png -text git check-attr text * A.png: text: unset B.txt: text: auto -------------------- This is not very intuitive or even surprising, at least for many people. Unless I mis-understand the problem, it may be that the documentation may be updated ? The general rule for writing .gitattributes is to specify the "wider" rules first, and then the more specific rules after that. It could be that Documentation/gitattributes.txt should mention this instead: ------------------------ * -text *.txt text *.vcproj eol=crlf *.sh eol=lf ------------------------ The other thing is to promote/mention the command "git check-attr text *" at a prominent place. > Intuitively it *feels* like either of the later lines should suppress > EOL translation in PNG files (assuming the PNG file has a NUL byte in > the first 8k, which this one did). > > It seems to me that setting "text=auto" should mean that Git uses its > heuristic to guess whether a particular file is text or not, and then > treats the file as if it had "text" or "-text" set. If the latter, then > EOL translation should be suppressed. > > It also seems to me that "binary" should imply "-eol". > > Michael > -- 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