BUG: Git checkout on Linux sets always CRLF regardless of core.eol

BUG: Git checkout on Linux sets always CRLF regardless of core.eol

[Alexander]

Hello,

I am trying to checkout out various 3rd party Git projects on Linux
and build them.
Some of them have text files created under Windows with CRLF endings
and it is not under my responsibility to change it.

Thus I have to force LF line ending for Git checkout (regardless of
which line endings the files have in the repo). I use the following
settings for that:

$ git config --system -l | grep core
core.eol=lf
$ git config --global -l | grep core
core.eol=lf

However it does not work. The issue is reproduced pretty fine on
https://github.com/winlibs/libjpeg project. This project does not have
.gitattributes file, therefore I expect that global settings must be
enough to force LF, but I observe different behavior:

$ git clone https://github.com/winlibs/libjpeg; file libjpeg/libjpeg.map
Cloning into 'libjpeg'...
...
libjpeg/libjpeg.map: ASCII text, with CRLF line terminators
(not only libjpeg.map, but a lot of *.c files also have CRLF if you check it)

libjpeg is an opensource project, so anyone can reproduce this issue
on a Linux host.

This makes me think that this it is either a bug or not documented behavior.
I tried various combinations with core.eol, core.autocrlf and even
global /etc/gitattributes file - nothing can force checkout with LF!

Could you please confirm whether it is a bug and provide the clear way
to bypass it.

My Git client version: 2.17.1. Please, see also
stackoverflow.com/questions/56546220/git-checks-out-crlf-instead-of-lf-on-linux.

--
Best Regards,
Aleksandr Samoilov
Build & Integration Ingenieur
Compart AG, 71034 Böblingen

Re: BUG: Git checkout on Linux sets always CRLF regardless of core.eol

[Torsten Bögershausen]

On Wed, Jun 12, 2019 at 12:48:00PM +0200, Alexander wrote:
> Hello,
>
> I am trying to checkout out various 3rd party Git projects on Linux
> and build them.
> Some of them have text files created under Windows with CRLF endings
> and it is not under my responsibility to change it.
>
> Thus I have to force LF line ending for Git checkout (regardless of
> which line endings the files have in the repo). I use the following
> settings for that:
>
> $ git config --system -l | grep core
> core.eol=lf
> $ git config --global -l | grep core
> core.eol=lf
>
> However it does not work. The issue is reproduced pretty fine on
> https://github.com/winlibs/libjpeg project. This project does not have
> .gitattributes file, therefore I expect that global settings must be
> enough to force LF, but I observe different behavior:
>
> $ git clone https://github.com/winlibs/libjpeg; file libjpeg/libjpeg.map
> Cloning into 'libjpeg'...
> ...
> libjpeg/libjpeg.map: ASCII text, with CRLF line terminators
> (not only libjpeg.map, but a lot of *.c files also have CRLF if you check it)
>
> libjpeg is an opensource project, so anyone can reproduce this issue
> on a Linux host.
>
> This makes me think that this it is either a bug or not documented behavior.
> I tried various combinations with core.eol, core.autocrlf and even
> global /etc/gitattributes file - nothing can force checkout with LF!
>
> Could you please confirm whether it is a bug and provide the clear way
> to bypass it.

I can do neither-nor, so to say.

Whenever there are CRLF in the repo,
there is no way for Git to change those into LF in the working tree.

The correct way is to normalize the repo:
user@linux:/tmp/libjpeg> git checkout -b normalize_EOL
user@linux:/tmp/libjpeg> echo "* text=auto" >.gitattributes
user@linux:/tmp/libjpeg> git add --renormalize .
user@linux:/tmp/libjpeg> git add .
user@linux:/tmp/libjpeg> git commit -m "Normalize the repo; add .gitattributes"

After that, send a pull request to the original author.

HTH
>
> My Git client version: 2.17.1. Please, see also
> stackoverflow.com/questions/56546220/git-checks-out-crlf-instead-of-lf-on-linux.
>
> --
> Best Regards,
> Aleksandr Samoilov
> Build & Integration Ingenieur
> Compart AG, 71034 Böblingen