This Git warning indicates that your file contains Windows-style line endings (CRLF) which will be converted to Unix-style line endings (LF) when committed. This is typically caused by Git's autocrlf setting and can be resolved by configuring line ending behavior.
When you add files to Git, it checks the line endings in your files. Different operating systems use different characters to represent the end of a line: - **Windows** uses CRLF (Carriage Return + Line Feed, \r\n) - **Unix/Linux/macOS** uses LF (Line Feed only, \n) This warning appears when Git detects that a file contains CRLF line endings, but your Git configuration (specifically `core.autocrlf`) is set to convert these to LF when storing the file in the repository. This is actually a helpful feature for cross-platform development. It ensures that files in your repository use consistent line endings (LF), which prevents unnecessary diffs caused by line ending changes and keeps your repository clean. The warning is informational - Git is telling you what conversion it will perform, not that something is wrong.
This warning is informational, not an error. Git is telling you it will normalize line endings when storing the file. This is often the desired behavior for cross-platform projects.
If you're working on a cross-platform project, this normalization is helpful - it prevents line ending differences from cluttering your diffs and history.
To proceed with the commit despite the warning:
git add .
git commit -m "Your commit message"The warning will not prevent your commit from succeeding.
Git's core.autocrlf setting controls automatic line ending conversion. Choose based on your situation:
On Windows (recommended for cross-platform projects):
git config --global core.autocrlf trueThis converts LF to CRLF when checking out, and CRLF to LF when committing. Best for Windows developers on mixed teams.
On macOS/Linux:
git config --global core.autocrlf inputThis converts CRLF to LF on commit but doesn't change files on checkout.
To disable conversion entirely:
git config --global core.autocrlf falseFiles are stored exactly as-is. Use this only for single-platform projects.
If you understand the conversion behavior and don't want to see the warning, you can disable it:
git config --global core.safecrlf falseAlternatively, to only warn (not block) on irreversible conversions:
git config --global core.safecrlf warnNote: This doesn't change the conversion behavior, just hides the message.
For consistent behavior across all contributors, create a .gitattributes file in your repository root:
# Set default behavior for all text files
* text=auto
# Explicitly set line endings for specific file types
*.sh text eol=lf
*.bash text eol=lf
*.bat text eol=crlf
*.cmd text eol=crlf
# Binary files that should not be modified
*.png binary
*.jpg binary
*.exe binaryThis overrides individual developer's core.autocrlf settings, ensuring everyone uses the same line endings.
Commit this file to your repository:
git add .gitattributes
git commit -m "Add .gitattributes for consistent line endings"If you've added a .gitattributes file or changed your autocrlf settings and want to apply the new settings to existing files:
# Stage all files for renormalization
git add --renormalize .
# Commit the normalized files
git commit -m "Normalize line endings"This re-applies the line ending rules to all tracked files. After this, everyone who pulls will have consistent line endings.
Configure your text editor to use the line endings appropriate for your project:
VS Code:
1. Open Settings (Ctrl+,)
2. Search for "eol"
3. Set "Files: Eol" to "\n" (LF) for Unix or "auto" to match the file
Or per-workspace in `.vscode/settings.json`:
{
"files.eol": "\n"
}JetBrains IDEs (IntelliJ, WebStorm, etc.):
1. Settings > Editor > Code Style
2. Set "Line separator" to "Unix and macOS (\n)"
This prevents the issue at the source by saving files with consistent line endings.
### Why LF is the Standard for Repositories
Most projects standardize on LF (Unix line endings) in the repository because:
1. Git itself was developed on Linux and expects LF
2. Diff tools work better with consistent line endings
3. CI/CD systems typically run on Linux
4. Shell scripts with CRLF endings fail on Unix systems
The core.autocrlf setting handles the conversion transparently, so Windows users still see CRLF in their working directory.
### The safecrlf Setting
The core.safecrlf setting controls whether Git warns or blocks potentially problematic conversions:
git config --global core.safecrlf true # Error on irreversible conversion
git config --global core.safecrlf warn # Warn but allow (default)
git config --global core.safecrlf false # No warningsAn "irreversible" conversion would be if a file contains both CRLF and LF, making it impossible to restore the original mixed endings.
### Handling Binary Files
Never let Git convert line endings in binary files. In your .gitattributes:
*.png binary
*.pdf binary
*.zip binaryOr use -text to mark files that shouldn't be normalized:
*.svg -text### Troubleshooting Persistent Warnings
If warnings persist after configuring .gitattributes:
1. Clear Git's cache of file attributes:
git rm --cached -r .
git reset --hard2. Or delete the Git index and check out fresh:
rm .git/index
git checkout HEAD -- .### Per-Repository vs Global Settings
- git config --global affects all repositories
- git config (without --global) affects only the current repository
- .gitattributes is stored in the repository and affects all contributors
For team projects, always prefer .gitattributes over relying on individual developer settings.
warning: BOM detected in file, this may cause issues
UTF-8 Byte Order Mark (BOM) detected in file
fatal: Server does not support --shallow-exclude
Server does not support --shallow-exclude
warning: filtering out blobs larger than limit
Git partial clone filtering large blobs warning
fatal: Server does not support --shallow-since
Server does not support --shallow-since in Git
kex_exchange_identification: Connection closed by remote host
Connection closed by remote host when connecting to Git server