Re: CRLF problems with Git on Win32

[Junio C Hamano <gitster-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>]

Steffen Prohaska <prohaska-wjoc1KHpMeg-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> writes:

> On Jan 8, 2008, at 8:47 PM, Junio C Hamano wrote:
>>
>> "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> writes:
>>
>>> My only suggestion is that we consider allowing the user that
>>> "explicitly told git to do so" be the project maintainer.  So if you
>>>
>>> 	echo * autodetectcrlf >.gitattributes
>>> 	git add .gitattributes
>>> 	git commit
>>>
>>> then users that clone your repo will get that default without
>>> having to
>>> be told to do something magic on clone.
>>>
>>> (And ideally I'd've hoped you could do that using the existing crlf
>>> attribute rather than having to invent something new, but maybe that
>>> doesn't work.)
>>
>> I think the project can mark text files as text with attributes
>> and if the port to the platform initialized core.autocrlf
>> appropriately for the platform everything should work as you
>> described.
>>
>> At least that is how I read the description of `crlf` in
>> gitattributes(5).
>
>
> But we do not want to mark a file as text but tell git to run its
> auto-detection and use the local default line endings.

My reading of the description of `crlf` in gitattributes(5) is:

    `crlf`
    ^^^^^^

    This attribute controls the line-ending convention.

    Set::

            Setting the `crlf` attribute on a path is meant to mark
            the path as a "text" file.  'core.autocrlf' conversion
            takes place without guessing the content type by
            inspection.


Notice "without guessing".