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

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Mar 10, 2015, 19:25 UTC
Message-ID: <54FF450F.7040506@alum.mit.edu>
In-Reply-To: <54FA1C7B.3040906@web.de>

On 03/06/2015 10:30 PM, Torsten Bögershausen wrote:

Show 6 quoted lines

> 
>> 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.

Show 10 quoted lines

> 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