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
[email protected]
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
