Why should I use core autocrlf true in Git

Question

I have a Git repository that is accessed from both Windows and OS X  and that I know already contains some files with CRLF line-endings  As far as I can tell  there are two ways to deal with this    Set core autocrlf to false everywhere  Follow the instructions here  echoed on GitHub s help pages  to convert the repository to contain only LF line-endings  and thereafter set core autocrlf to true on Windows and input on OS X  The problem with doing this is that if I have any binary files in the repository that     are not correctly marked as binary in gitattributes  and  happen to contain both CRLFs and LFs    they will be corrupted  It is possible my repository contains such files    So why shouldn t I just turn off Git s line-ending conversion  There are a lot of vague warnings on the web about having core autocrlf switched off causing problems  but very few specific ones  the only that I ve found so far are that kdiff3 cannot handle CRLF endings  not a problem for me   and that some text editors have line-ending issues  also not a problem for me    The repository is internal to my company  and so I don t need to worry about sharing it with people with different autocrlf settings or line-ending requirements   Are there any other problems with just leaving line-endings as-is that I am unaware of

User · Answer

Update 2   Xcode 9 appears to have a  feature  where it will ignore the file s current line endings  and instead just use your default line-ending setting when inserting lines into a file  resulting in files with mixed line endings   I m pretty sure this bug didn t exist in Xcode 7  not sure about Xcode 8  The good news is that it appears to be fixed in Xcode 10   For the time it existed  this bug caused a small amount of hilarity in the codebase I refer to in the question  which to this day uses autocrlf false   and led to many  EOL  commit messages and eventually to my writing a git pre-commit hook to check for prevent introducing mixed line endings   Update   Note  As noted by VonC  starting from Git 2 8  merge markers will not introduce Unix-style line-endings to a Windows-style file     Original   One little hiccup that I ve noticed with this setup is that when there are merge conflicts  the lines git adds to mark up the differences do not have Windows line-endings  even when the rest of the file does  and you can end up with a file with mixed line endings  e g       Some code lt CR gt  lt LF gt   lt  lt  lt  lt  lt  lt  lt  Updated upstream lt LF gt     Change A lt CR gt  lt LF gt          lt LF gt     Change B lt CR gt  lt LF gt   gt  gt  gt  gt  gt  gt  gt  Stashed changes lt LF gt     More code lt CR gt  lt LF gt    This doesn t cause us any problems  I imagine any tool that can handle both types of line-endings will also deal sensible with mixed line-endings--certainly all the ones we use do   but it s something to be aware of   The other thing  we ve found  is that when using git diff to view changes to a file that has Windows line-endings  lines that have been added display their carriage returns  thus          Not changed         New line added in M   M        Not changed        Not changed     It doesn t really merit the term   issue

User · Answer

For me  Edit  gitattributes file  add   dll binary  Then everything goes well

User · Answer

I am a  NET developer  and have used Git and Visual Studio for years  My strong recommendation is set line endings to true  And do it as early as you can in the lifetime of your Repository   That being said  I HATE that Git changes my line endings  A source control should only save and retrieve the work I do  it should NOT modify it  Ever  But it does   What will happen if you don t have every developer set to true  is ONE developer eventually will set to true  This will begin to change the line endings of all of your files to LF in your repo  And when users set to false check those out  Visual Studio will warn you  and ask you to change them  You will have 2 things happen very quickly  One  you will get more and more of those warnings  the bigger your team the more you get  The second  and worse thing  is that it will show that every line of every modified file was changed because the line endings of every line will be changed by the true guy   Eventually you won t be able to track changes in your repo reliably anymore  It is MUCH easier and cleaner to make everyone keep to true  than to try to keep everyone false  As horrible as it is to live with the fact that your trusted source control is doing something it should not  Ever

User · Answer

The only specific reasons to set autocrlf to true are    avoid git status showing all your files as modified because of the automatic EOL conversion done when cloning a Unix-based EOL Git repo to a Windows one  see issue 83 for instance  and your coding tools somehow depends on a native EOL style being present in your file    for instance  a code generator hard-coded to detect native EOL other external batches  external to your repo  with regexp or code set to detect native EOL I believe some Eclipse plugins can produce files with CRLF regardless on platform  which can be a problem  You code with Notepad exe  unless you are using a Windows 10 2018 09   where Notepad respects the EOL character detected      Unless you can see specific treatment which must deal with native EOL  you are better off leaving autocrlf to false  git config --global core autocrlf false    Note that this config would be a local one  because config isn t pushed from repo to repo   If you want the same config for all users cloning that repo  check out  What s the best CRLF handling strategy with git    using the text attribute in the  gitattributes file   Example     vcproj    text eol crlf   sh        text eol lf     Note  starting git 2 8  March 2016   merge markers will no longer introduce mixed line ending  LF  in a CRLF file  See  Make Git use CRLF on its     lt  lt  lt  lt  lt  lt  lt  HEAD    merge lines

[git] Why should I use core.autocrlf=true in Git?

Examples related to git

Examples related to line-endings