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

[Michael Haggerty <mhagger@alum.mit.edu>]

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

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

-- 
Michael Haggerty
mhagger@alum.mit.edu