Line Endings

The Hook (The "Byte-Sized" Intro)

Line endings are invisible until they destroy your diff. Windows uses \r\n (CRLF), macOS/Linux use \n (LF). Without configuration, one Windows developer can make every file appear "changed" to every Linux developer — hundreds of lines modified, zero actual code changes. Git can handle this automatically if you tell it how.

📖 What are Line Endings?

Different operating systems use different characters to mark the end of a line. Git provides tools to convert between them automatically, preventing cross-platform conflicts.

Conceptual Clarity

The line ending problem:

OS	Line Ending	Characters
Windows	CRLF	`\r\n` (Carriage Return + Line Feed)
macOS / Linux	LF	`\n` (Line Feed only)
Old macOS (pre-X)	CR	`\r` (Carriage Return only)

Git's solution: core.autocrlf:

Value	On Checkout	On Commit	Use When
`true`	LF → CRLF	CRLF → LF	Windows
`input`	No change	CRLF → LF	macOS / Linux
`false`	No change	No change	Consistent team

The .gitattributes approach (recommended):

# Force LF for all text files
* text=auto eol=lf

# Keep CRLF for Windows-specific files
*.bat text eol=crlf
*.cmd text eol=crlf

Real-Life Analogy

Line endings are like paper sizes. US uses Letter, Europe uses A4. If you share documents without converting, they don't print correctly. .gitattributes is like agreeing on one paper size for the entire project.

Visual Architecture

flowchart LR WIN["🪟 Windows: CRLF"] --> GIT["📦 Git Repo: LF"] MAC["🍎 macOS: LF"] --> GIT LINUX["🐧 Linux: LF"] --> GIT GIT -->|"checkout"| WIN2["CRLF on Windows"] GIT -->|"checkout"| MAC2["LF on macOS"] style GIT fill:#0f3460,stroke:#53d8fb,color:#53d8fb

Why It Matters

Cross-platform: Teams with mixed OS must handle line endings.
Clean diffs: Wrong settings cause every line to show as changed.
Consistency: .gitattributes ensures the same behavior for everyone.
Build issues: Some tools and scripts fail with wrong line endings.

Code

bash

# ─── Configure per-user (fallback) ───
# Windows:
git config --global core.autocrlf true
# macOS / Linux:
git config --global core.autocrlf input

# ─── Better: project-wide .gitattributes ───
cat > .gitattributes << 'EOF'
# Normalize all text files to LF
* text=auto eol=lf

# Windows batch files need CRLF
*.bat text eol=crlf
*.cmd text eol=crlf

# Binary files - don't touch
*.png binary
*.jpg binary
*.zip binary
EOF

git add .gitattributes
git commit -m "chore: add .gitattributes for consistent line endings"

# ─── Fix existing files after adding .gitattributes ───
git rm --cached -r .
git reset --hard
# This re-normalizes all files

Key Takeaways

Windows uses CRLF, macOS/Linux use LF — mixing them creates noisy diffs.
.gitattributes (committed to repo) is better than core.autocrlf (per-user).
Store files as LF in the repo; convert to CRLF only on Windows checkout.
After adding .gitattributes, re-normalize with git rm --cached -r . && git reset --hard.

Interview Prep

Q: What is the line ending problem in Git? A: Windows uses CRLF (\r\n) and macOS/Linux use LF (\n). Without configuration, cross-platform teams see false diffs where every line appears changed because the line ending characters differ.
Q: What is the difference between core.autocrlf and .gitattributes? A: core.autocrlf is a per-user setting — each developer must configure it. .gitattributes is committed to the repo and applies to everyone automatically. .gitattributes is the recommended approach for team consistency.
Q: How do you normalize line endings in an existing repo? A: Add a .gitattributes file with * text=auto eol=lf, then run git rm --cached -r . && git reset --hard to re-checkout all files with the correct line endings.