Git LF and CRLF: Inspect Line Endings Before Bulk Changes

You edit one line, but review highlights almost the entire file. A change between LF and CRLF is one possible cause. Before formatting the repository or changing global Git settings, identify the affected file and inspect what Git sees.

1. Separate text from line endings

LF and CRLF represent line endings differently. Text can look identical in an editor while its on-disk bytes differ. This is separate from UTF-8 encoding, accented text or trailing blank lines.

A Linux shell script saved with CRLF after editing on Windows illustrates the problem. Looking correct in an editor does not establish compatibility with its runtime. Start with a specific file.

2. Inspect index and working-tree content

git status --short
git ls-files --eol -- scripts/check.sh

Replace the sample path with a tracked file. The git ls-files manual documents --eol output for index content, working-tree content and related attributes.

i/lf    w/crlf    attr/text eol=crlf    scripts/check.sh

This is illustrative output, not a finding from your repository. i/lf describes the index; w/crlf describes the working copy. Different values can reflect deliberate conversion rather than corruption. mixed indicates mixed line endings.

3. Check effective attributes

git check-attr text eol -- scripts/check.sh
git check-attr --cached text eol -- scripts/check.sh

git check-attr reports path attributes. --cached uses .gitattributes from the index instead of the working tree. Comparing both helps when attribute rules have unstaged edits.

unspecified does not mean a file has no line endings. It means that attribute is not specified through the mechanism being inspected. Examine Git configuration and editor settings rather than assuming a particular policy.

4. Read configuration before changing it

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

These commands reveal values and their configuration sources. Empty output can simply mean no explicit setting; it is not a reason to invent a global value.

When the team establishes .gitattributes rules, review their scope. Adding rules does not mean all tracked content has already been normalized. Treat normalization as a separate change, protect current work and inspect staged differences.

5. Keep corrections scoped

Confirm the target is text and determine the line endings its consumer expects. Never run a text converter over images, archives or binary data. For generated files, correct the source or generator settings so the problem does not return.

Separate broad normalization from functional changes. A patch combining thousands of formatting differences with logic changes is harder to review and debug.

• Identify the file and distinguish index from working tree.
• Inspect attributes, Git configuration and editor settings.
• Preserve other people's work in progress.
• Convert only agreed text-file targets.
• Review the diff and test in the actual consumer environment.

All commands shown inspect state without converting line endings. Understanding the source of a difference enables a small, verifiable correction.