Skip to main content
DevOps Insightsguides & answers

Git · troubleshooting

warning: LF will be replaced by CRLF the next time Git touches it

A warning, not an error: Git is set to convert line endings, and this file will get different ones in your working folder at its next checkout. Your commit still worked.

Reproduced on Git 2.50.1, . Where the text says “reproduced”, the behaviour was run on that version, not taken from documentation.

First published

New to this? Read what is actually happening first, then come back to the steps.

On this page · 8 sections

Before you start

  • The file named in the warning, and whether the people on the project use Windows, macOS or Linux.

Run this first

step 1 of 2
git ls-files --eol FILE

Look for Whether i/ and w/ differ, and whether any attr rule is set

Shows the line endings in the repository (i/), in your folder (w/) and the rule that applies (attr/).

Work out which cause you have

A few questions to narrow the list. Every answer ends in a command that confirms or rules the cause out — this cannot see your cluster, so nothing here is a certainty until you have checked.

Narrow it down

0 answered · nothing is sent anywhere

Is anything actually broken, such as a script that fails?

Cause space

3 of 3 still possible

  • core.autocrlf=true on a machine that is not Windows, or on a repository of LF filesCommon
  • The repository does not decide its own line endingsCommon
  • The endings matter: a script or config now breaksOccasional

Nothing ruled out yet. Answer the question above and the branches your answer eliminates will strike through here.

Or diagnose it manually

In this order. The first command usually contains the whole answer.

  1. Step 1

    git ls-files --eol FILE

    Shows the line endings in the repository (i/), in your folder (w/) and the rule that applies (attr/).

    Look for Whether i/ and w/ differ, and whether any attr rule is set

  2. Step 2

    git config --show-origin --get core.autocrlf

    Shows the conversion setting and which config file sets it.

    Look for true, input, false, or nothing

Every cause, and how to fix it

Ordered by how often each one turns out to be the answer.

core.autocrlf=true on a machine that is not Windows, or on a repository of LF files

Common

The setting is meant for Windows working copies. On macOS or Linux, or in a project that wants LF everywhere, it rewrites files you did not intend to change.

Confirm

git config --show-origin --get core.autocrlf

true, and the file it is set in (your global config, or the system one an installer wrote)

Fix

  • On macOS and Linux, use input (convert CRLF to LF on commit only) or false: git config --global core.autocrlf input.
  • On Windows, true is the usual choice, and the warning is expected and harmless for most files.

The repository does not decide its own line endings

Common

Without .gitattributes, each person's Git settings decide, so the same file can be committed and checked out differently on different machines.

Confirm

git ls-files --eol | head

i/ (in the repository) and w/ (in your folder) values that differ, or no attr/ rule

Fix

  • Commit a .gitattributes that states the rules for everyone, for example * text=auto eol=lf, and *.bat text eol=crlf if you keep Windows batch files.
  • Renormalise only the files you mean to, by pathspec, and review the diff before committing: git add --renormalize -- '*.sh'.

The endings matter: a script or config now breaks

Occasional

Shell scripts with CRLF fail with bad interpreter or unexpected end of file, and some config parsers reject them. That is when this warning stops being harmless.

Confirm

git ls-files --eol -- '*.sh'

w/crlf on a script

Fix

  • Pin scripts to LF in .gitattributes: *.sh text eol=lf, then check them out again.

Understanding it properly

Skip this if you are mid-incident — the working part of the page is above. Worth reading afterwards, because understanding the mechanism is what stops the next one.

In plain terms

Windows ends lines with two characters (CRLF), Linux and macOS with one (LF). Git can convert between them as files go in and out of the repository, which core.autocrlf turns on. This message says that conversion is about to change a file. It matters only when the wrong endings reach a tool that cares, such as a shell script.

Words used on this page

CRLF and LF
The two common ways to end a line. Most tools accept either; shells and some parsers do not.
core.autocrlf
A Git setting: true converts to CRLF on checkout and back to LF on commit; input only converts to LF on commit; false converts nothing.
.gitattributes
A file in the repository that fixes line-ending rules for everyone, whatever their own Git settings.
What is actually happening

Reproduced with Git 2.50.1 on macOS and Git 2.43.0 on Ubuntu, which print the same words. With core.autocrlf=true, adding a file with LF endings printed "warning: in the working copy of 'lf.txt', LF will be replaced by CRLF the next time Git touches it", and the add and commit both succeeded.

"The next time Git touches it" is literal: after the file was deleted and checked out again, it had CRLF endings in the working folder, while the repository kept LF. git ls-files --eol showed exactly that: i/lf w/crlf.

Git's documentation describes core.autocrlf=true as the same as text=auto on every file with CRLF on checkout. A .gitattributes with * text=auto alone did not silence the warning under that setting; * text=auto eol=lf did, and kept the working copy in LF.

How to tell this is your problem
WhereWhat you see
git add, autocrlf=truewarning: in the working copy of 'FILE', LF will be replaced by CRLF the next time Git touches it
git add, autocrlf=inputwarning: in the working copy of 'FILE', CRLF will be replaced by LF the next time Git touches it

How to know it is actually fixed

  • git add no longer warns for files you meant to keep in LF, and git ls-files --eol shows the endings you chose.

Stopping it happening again

  • Keep line-ending rules in .gitattributes in the repository, not in each person's Git settings.
  • Pin anything executed on Linux, shell scripts above all, to eol=lf.

Sources

Behaviour described here is drawn from official documentation. Where a figure could not be confirmed on an official page it is attributed in the text rather than stated as canonical.

Did this get you to an answer?

No text box on purpose — please do not paste production logs anywhere

Something wrong or out of date? Report it

Where to go next