“warning: LF will be replaced by CRLF the next time Git touches it”
If you’ve worked with Git and you’ve developed a project in different operating systems, you’ve probably come across this statement. Here we’ll explain what does it mean and how you can fix it.
CRLF and LF are two terms used to distinguish the line endings applied on text files by different operating systems. They probably ring a bell if you’ve ever seen a warning message like the one above when using Git.
CRLF stands for “Carriage Return, Line Feed”, a term inherited from the typewriters time. This is the setting applied by Windows, which signals line endings through the following special characters \r\n.
On the other hand, LF stands only for “Line Feed”, which uses the special character newline \n for marking end of lines. This is the option chosen by Unix-based systems.
Coming back to the warning we’ve seen above: >“warning: LF will be replaced by CRLF the next time Git touches it”
What does this mean?
It means that the newline line endings from Unix-based systems will be replaced by carriage-return + newline line endings at the end of the commit-checkout cycle. It is usually shown though when you use git add with a file, as it proactively warns you about what will happen after you do the commit.
Now, what’s the commit-checkout cycle?
There are two conversion steps that Git can do for you related with LF and CRLF. Let’s imagine you’ve got a source txt file which is called x and has been created on Windows. Hence, it’s line endings are CRLF-based.
When you commit the file, you move it into a repository state. The contents of the repo at this specific commit are stored under the .git folder. After that, when you bring back the files from the Git repository, you’re checking out (for instance when you git clone, or when you git checkout into a specific branch with different contents).
This is what we understand as the commit-checkout cycle, two steps involved in version control storage and retrieval.
Going back to our previous explanation. If we see a warning regarding that LF will be replaced by CRLF, and we know that’s at the end of the commit-checkout cycle: it will imply that, upon checkout, the current LF-based file x, will be retrieved as CRLF.
Why does this appear? Because Git is warning you that it will automatically do that transformation for you. Now, it won’t always do so. It depends on the core.autocrlf setting. Here’s a table of what settings you can specify and their implications, borrowed from this great StackOverFlow response:
core.autocrlf=true: core.autocrlf=input: core.autocrlf=false:
repository repository repository
^ V ^ V ^ V
/ \ / \ / \
crlf->lf lf->crlf crlf->lf \ / \
/ \ / \ / \
(original) (checkout) (original) (checkout) (original) (checkout)You’ve got three possible settings: true, input and false.
true is the best option for Windows developers, as it will use CRLF when checking out files, but it will commit them to the repo as LF, which is more standard as it’s Unix-based. Later on, when doing git clone or checkout or any other operation, Git will reapply the CRLF line endings, a smooth conversion that will prevent Windows crashes from using wrong line-endings.
On the other hand, input only transforms into LF at commit time, but it doesn’t do any conversion at checkout. Hence, it’s best for Unix-based development. Using the example above, the Windows dev has pushed changes to a repo with core.autocrlf set to true. Now, the files have been stored with LF line endings. If a second Unix dev pulls the files using the input setting, these line endings will be preserved, and the file will work seamlessly in a Unix-based OS.
Finally, false doesn’t do any type of conversion, neither at commit nor at checkout time. Interesting if you’re handling these issues through different software.
So, taking all this into account, what I’d do is the following. Use input if I’m working on Linux (or WSL), and true if I’m working on Windows.
Now, regarding the warning, what does it mean that LF will be replaced by CRLF the next time Git touches it? This happens when you’re using the core.autocrlf setting in true mode since, at checkout, a file that was originally LF (Unix-based file) will be shown as CRLF.
It happens the other way round if we’re using input and seeing a CRLF file. After checkout, the file will be shown as LF. Git is just trying to warn you.
Finally, if you’re working on a cross-platform team, consider adding a .gitattributes file to the repository root (e.g., with * text=auto) to enforce uniform behavior across all contributors, overriding individual configs.