git replacing LF with CRLF

Question

Running git on a Windows XP machine, using bash. I exported my project from SVN, and then cloned a bare repository.

I then pasted the export into the bare repositori

Answer 1

A GitHub's article on line endings is commonly mentioned when talking about this topic.

My personal experience with using the often recommended core.autocrlf config setting was very mixed.

I'm using Windows with Cygwin, dealing with both Windows and UNIX projects at different times. Even my Windows projects sometimes use bash shell scripts, which require UNIX (LF) line endings.

Using GitHub's recommended core.autocrlf setting for Windows, if I check out a UNIX project (which does work perfectly on Cygwin - or maybe I'm contributing to a project that I use on my Linux server), the text files are checked out with Windows (CRLF) line endings, creating problems.

Basically, for a mixed environment like I have, setting the global core.autocrlf to any of the options will not work well in some cases. This option might be set on a local (repository) git config, but even that wouldn't be good enough for a project that contains both Windows- and UNIX-related stuff (e.g. I have a Windows project with some bash utility scripts).

The best choice I've found is to create per-repository .gitattributes files. The GitHub article mentions it.
Example from that article:

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

In one of my project's repository:

* text=auto

*.txt         text eol=lf
*.xml         text eol=lf
*.json        text eol=lf
*.properties  text eol=lf
*.conf        text eol=lf

*.awk  text eol=lf
*.sed  text eol=lf
*.sh   text eol=lf

*.png  binary
*.jpg  binary

*.p12  binary

It's a bit more things to set up, but do it once per project, and any contributor on any OS should have no troubles with line endings when working with this project.

Answer 2

It should read:

warning: (If you check it out/or clone to another folder with your current core.autocrlf being true,)LF will be replaced by CRLF

The file will have its original line endings in your (current) working directory.

This picture should explain what it means.

Answer 3

Make sure that you have installed the latest git.
I did as above git config core.autocrlf false, when used git (version 2.7.1), but it did not work.
Then it works now when upgrade git (from 2.7.1 to 2.20.1).

Answer 4

Most of tools in Windows accepts only LF in text files. For example you can control the behaviour for Visual Studio in a file named '.editorconfig' with following example content (part):

 indent_style = space
 indent_size = 2
 end_of_line = lf    <<====
 charset = utf-8

Only the original Windows-Notepad does not work with LF but there are some more proper simple editor tools available!

Hence You should use LF in text files in Windows too. This is my message, stronlgy recommended! There is no reason to use CRLF in windows!

(The same discussion is using \ in include paths in C/++, it is bullshit, use #include <pathTo/myheader.h> with slash!, It is the C/++ standard and all microsoft compilers support it).

Hence the proper setting for git is

git config core.autocrlf false

My message: Forget such old thinking programs as dos2unix and unix2dos. Clarify in your team that LF is proper to use under Windows.

Answer 5

If you already have checked out the code, the files are already indexed. After changing your git settings, say by running:

git config --global core.autocrlf input 

you should refresh the indexes with

git rm --cached -r . 

and re-write git index with

git reset --hard

https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings

Note: this is will remove your local changes, consider stashing them before you do this.

Answer 6

Both unix2dos and dos2unix is available in windows with gitbash. You can use the following command to perform UNIX(LF) -> DOS(CRLF) conversion. Hence, you will not get the warning.

unix2dos filename

or

dos2unix -D filename

But, don't run this command on any existing CRLF file, then you will get empty newlines every second line.

dos2unix -D filename will not work with every operating system. Please check this link for compatibility.

If for some reason you need to force the command then use --force. If it says invalid then use -f.