Re: Surprising interaction of "binary" and "eol" gitattributes

["Torsten Bögershausen" <tboegi@web.de>]

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
>