Re: CRLF problems with Git on Win32

Steffen Prohaska [off-list ref] writes:

On Jan 8, 2008, at 8:47 PM, Junio C Hamano wrote:

quoted

"J. Bruce Fields" [off-list ref] writes:

quoted

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