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 repositories directory  and did a   git add -A   I then got a list of messages saying      LF will be replaced by CRLF   What are the ramifications of this conversion  This is a  NET solution in Visual Studio

User · Answer

http   www rtuin nl 2013 02 how-to-make-git-ignore-different-line-endings   echo    -crlf   gt   gitattributes    Do this on a separate commit or git might still see whole files as modified when you make a single change  depending on if you have changed autocrlf option   This one really works  Git will respect the line endings in mixed line ending projects and not warning you about them

User · Answer

In vim open the file  e g    e YOURFILEENTER   then   set noendofline binary  wq

User · Answer

I don t know much about git on Windows  but     Appears to me that git is converting the return format to match that of the running platform  Windows    CRLF is the default return format in Windows  while LF is the default return format for most other OSes   Chances are  the return format will be adjusted properly when the code is moved to another system   I also reckon git is smart enough to keep binary files intact rather than trying to convert LFs to CRLFs in  say  JPEGs   In summary  you probably don t need to fret too much over this conversion   However  if you go to archive your project as a tarball  fellow coders would probably appreciate having LF line terminators rather than CRLF   Depending on how much you care  and depending on you not using Notepad   you might want to set git to use LF returns if you can     Appendix   CR is ASCII code 13  LF is ASCII code 10   Thus  CRLF is two bytes  while LF is one

User · Answer

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

User · Answer

These messages are due to incorrect default value of core autocrlf on Windows  The concept of autocrlf is to handle line endings conversions transparently  And it does  Bad news  value needs to be configured manually  Good news  it should only be done ONE time per git installation  per project setting is also possible   How autocrlf works  core autocrlf true       core autocrlf input      core autocrlf false                                                        repo                     repo                     repo              V                        V                        V                                                                   crlf- gt lf    lf- gt crlf     crlf- gt lf                                                                                                             Here crlf   win-style end-of-line marker  lf   unix-style  and mac osx    pre-osx cr in not affected for any of three options above  When does this warning show up  under Windows               autocrlf   true if you have unix-style lf in one of your files    RARELY                autocrlf   input if you have win-style crlf in one of your files    almost ALWAYS                autocrlf   false     NEVER  What does this warning mean The warning  quot LF will be replaced by CRLF quot  says that you  having autocrlf true  will lose your unix-style LF after commit-checkout cycle  it will be replaced by windows-style CRLF   Git doesn t expect you to use unix-style LF under windows  The warning  quot CRLF will be replaced by LF quot  says that you  having autocrlf input  will lose your windows-style CRLF after a commit-checkout cycle  it will be replaced by unix-style LF   Don t use input under windows  Yet another way to show how autocrlf works 1  true              x - gt  LF - gt  CRLF 2  input             x - gt  LF - gt  LF 3  false             x - gt  x - gt  x  where x is either CRLF  windows-style  or LF  unix-style  and arrows stand for file to commit - gt  repository - gt  checked out file  How to fix Default value for core autocrlf is selected during git installation and stored in system-wide gitconfig   ProgramFiles x86   git etc gitconfig    Also there re  cascading in the following order              quot global quot   per-user  gitconfig located at    gitconfig  yet another            quot global quot   per-user  gitconfig at  XDG CONFIG HOME git config or  HOME  config git config and            quot local quot   per-repo  gitconfig at  git config in the working dir  So  write git config core autocrlf in the working dir to check the currently used value and           add autocrlf false to system-wide gitconfig                  per-system solution           git config --global core autocrlf false                          per-user solution           git config --local core autocrlf false                              per-project solution Warnings     git config settings can be overridden by gitattributes settings      crlf - gt  lf conversion only happens when adding new files  crlf files already existing in the repo aren t affected  Moral  for Windows           -  use core autocrlf   true if you plan to use this project under Unix as well  and unwilling to configure your editor IDE to use unix line endings           -  use core autocrlf   false if you plan to use this project under Windows only  or you have configured your editor IDE to use unix line endings           -  never use core autocrlf   input unless you have a good reason to  eg if you re using unix utilities under windows or if you run into makefiles issues   PS What to choose when installing git for Windows  If you re not going to use any of your projects under Unix  don t agree with the default first option  Choose the third one  Checkout as-is  commit as-is   You won t see this message  Ever  PPS My personal preference is configuring the editor IDE to use Unix-style endings  and setting core autocrlf to false

User · Answer

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

User · Answer

Removing the below from the    gitattributes file    text auto  will prevent git from checking line-endings in the first-place

User · Answer

Open the file in the Notepad    Go to Edit EOL Conversion  Click to the Windows Format  Save the file

User · Answer

Many text-editors allow you to change to LF  see Atom instructions below  Simple and explicit     Click CRLF on bottom right     Select LF in dropdown on top

User · Answer

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     lt  lt       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  lt 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

User · Answer

I think  Basiloungas s answer is close but out of date  at least on Mac    Open the    gitconfig file and set safecrlf to false   core         autocrlf   input        safecrlf   false   That  will make it ignore the end of line char apparently  worked for me  anyway

User · Answer

Git has three modes of how it treats line endings     git config core autocrlf   that command will print  true  or  false  or  input    You can set the mode to use by adding an additional parameter of true or false to the above command line   If core autocrlf is set to true  that means that any time you add a file to the git repo that git thinks is a text file  it will turn all CRLF line endings to just LF before it stores it in the commit   Whenever you git checkout something  all text files automatically will have their LF line endings converted to CRLF endings   This allows development of a project across platforms that use different line-ending styles without commits being very noisy because each editor changes the line ending style as the line ending style is always consistently LF   The side-effect of this convenient conversion  and this is what the warning you re seeing is about  is that if a text file you authored originally had LF endings instead of CRLF  it will be stored with LF as usual  but when checked out later it will have CRLF endings   For normal text files this is usually just fine   The warning is a  for your information  in this case  but in case git incorrectly assesses a binary file to be a text file  it is an important warning because git would then be corrupting your binary file     If core autocrlf is set to false  no line-ending conversion is ever performed  so text files are checked in as-is   This usually works ok  as long as all your developers are either on Linux or all on Windows   But in my experience I still tend to get text files with mixed line endings that end up causing problems   My personal preference is to leave the setting turned ON  as a Windows developer   See http   kernel org pub software scm git docs git-config html for updated info that includes the  input  value

User · Answer

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

User · Answer

git config core autocrlf false

User · Answer

OP s question is windows related and I could not use others without going to the directory or even running file in Notepad   as administrator did not work   So had to go this route   C  Program Files  x86  Git etc gt git config --global core autocrlf false

User · Answer

In a GNU Linux shell prompt  dos2unix  amp  unix2dos commands allow you to easely convert format your files coming from MS Windows

User · Answer

CRLF could cause some problem while using your  code  in two different OS  Linux and Windows   My python script was written in Linux docker container and then pushed using Windows git-bash  It gave me the warning that LF will be replaced by CRLF  I didn t give it much thought but then when I started the script later  it said  usr bin env   python r   No such file or directory  Now that an  r for ramification for you  Windows uses  CR  - carriage return - on top of   n  as new line character -  n r  That s something you might have to consider

User · Answer

I had this problem too   SVN doesn t do any line ending conversion  so files are committed with CRLF line endings intact  If you then use git-svn to put the project into git then the CRLF endings persist across into the git repository  which is not the state git expects to find itself in - the default being to only have unix linux  LF  line endings checked in   When you then check out the files on windows  the autocrlf conversion leaves the files intact  as they already have the correct endings for the current platform   however the process that decides whether there is a difference with the checked in files performs the reverse conversion before comparing  resulting in comparing what it thinks is an LF in the checked out file with an unexpected CRLF in the repository   As far as I can see your choices are    Re-import your code into a new git repository without using git-svn  this will mean line endings are converted in the intial git commit --all Set autocrlf to false  and ignore the fact that the line endings are not in git s preferred style Check out your files with autocrlf off  fix all the line endings  check everything back in  and turn it back on again  Rewrite your repository s history so that the original commit no longer contains the CRLF that git wasn t expecting   The usual caveats about history rewriting apply      Footnote  if you choose option  2 then my experience is that some of the ancillary tools  rebase  patch etc  do not cope with CRLF files and you will end up sooner or later with files with a mix of CRLF and LF  inconsistent line endings   I know of no way of getting the best of both

User · Answer

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

User · Answer

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

[linux] git replacing LF with CRLF

Examples related to linux

Examples related to windows

Examples related to git

Examples related to newline

Examples related to lf