Re: [PATCH master] convert: The native line-ending is \r\n on MinGW

Jonathan Nieder [off-list ref] writes:

If you try this:

 1. Install Git for Windows (from the msysgit project)
 2. Put

	[core]
		autocrlf = false
		eol = native

    in your .gitconfig.
 3. Clone a project with

	*.txt text

    in its .gitattributes.

Then with current git, any text files checked out have LF line
endings, instead of the expected CRLF.

Cc: Johannes Schindelin <redacted>
Cc: Johannes Sixt <redacted>
Signed-off-by: Jonathan Nieder <redacted>
---
Eyvind Bernhardsen wrote:

quoted

Introduce a new configuration variable, "core.eol", that allows the user
to set which line endings to use for end-of-line-normalized files in the
working directory.  It defaults to "native", which means CRLF on Windows
and LF everywhere else.

The following fixup has been sitting in my tree (but not tested on
Windows) for a couple of weeks.  Sensible?

I don't know what the right choice for Cygwin is; probably LF unless
there is some way to detect the systemwide setting at run time.

Has anybody in Windows land any input?  I don't think what I do before
1.7.3 in my tree would matter much, so I am not applying this myself.

Junio C Hamano wrote:

Jonathan Nieder [off-list ref] writes:

quoted

quoted

Introduce a new configuration variable, "core.eol", that allows the user
to set which line endings to use for end-of-line-normalized files in the
working directory.  It defaults to "native", which means CRLF on Windows
and LF everywhere else.

The following fixup has been sitting in my tree (but not tested on
Windows) for a couple of weeks.  Sensible?

I don't know what the right choice for Cygwin is; probably LF unless
there is some way to detect the systemwide setting at run time.

Has anybody in Windows land any input?  I don't think what I do before
1.7.3 in my tree would matter much, so I am not applying this myself.

Sorry for the late reply to this; I've only just noticed that I hadn't
replied! ;-)

FWIW, I suspect that anything other than LF as the eol on Cygwin would
be *insane*. ;-D

ATB,
Ramsay Jones

I am on windows 7 Pro - mingwin

I decided to turn autocrlf to false and use .gitattributes instead and was
bitten by this bug :

http://stackoverflow.com/questions/13531988/git-line-endings-renormalize-does-not-seem-to-checkout-the-right-line-endings

It took me 2 days to figure this out

Please fix



--
View this message in context: http://git.661346.n2.nabble.com/PATCH-v6-Add-core-eol-config-variable-tp5140844p7571889.html
Sent from the git mailing list archive at Nabble.com.

Mr_and_Mrs_D <the.ubik <at> gmail.com> writes:

I am on windows 7 Pro - mingwin

I decided to turn autocrlf to false and use .gitattributes instead and was

bitten by this bug :

http://stackoverflow.com/questions/13531988/git-line-endings-renormalize-

does-not-seem-to-checkout-the-right-line-endings

It took me 2 days to figure this out

Please fix

--

View this message in context: http://git.661346.n2.nabble.com/PATCH-v6-

Add-core-eol-config-variable-tp5140844p7571889.html

Sent from the git mailing list archive at Nabble.com.

+1, this is a significant issue downstream in Git for Windows:



https://github.com/msysgit/git/issues/57



Effectively this renders .gitattributes useless for the scenario of 
enforcing normalized line ending characters.

Brice Lambson <bricelam <at> live.com> writes:

+1, this is a significant issue downstream in Git for Windows:

https://github.com/msysgit/git/issues/57

Effectively this renders .gitattributes useless for the scenario of 
enforcing normalized line ending characters.

+100

Folks, the problem is still there, with the very latest Git built with MinGW 
on Windows. Having eol=native in gitattributes means *LF* EOLs on 
Windows/MinGW.

So, essentially, eol=native is completely broken. And this is the most useful 
option to put into gitattributes and share among those working on the project.

Currently, I have to put eol=crlf there, and that means that those working on 
Linux will end up with CRLF files in their working copies.

The link quoted above does contain an additional fix that resolves the 
problem.

Thanks,
  --Tvangeste